Convention over Git or CoG influences on automated conflict solving during automated synchronization of remote Git repositories. Naming convention The Convention over Git uses naming to define owners of Git-branches. More often I use prefixed names for this. I.e. each remote Git repository owns its prefix. (It allows for all non-fast-forward Git-conflicts to be solved in favor of a prefix owner.) Examples Let's say one team uses prefix "company1/". (Git allows you have slashes in branch names) And another team uses "company2-". For this we may have flogging synchronized Git-branches. company1/develop vs company2-develop company1/JIRA-123 vs company2-JIRA-321 or simply company1/my-cool-feature company2-my-bug-fixing So, a naming convention in Git can be any conventional separation of names. It depends on you implementation. I use prefixes in my implementations. Results Conventions over Git gives many advantages and drastically ...
Convention-Over-Git One of the approaches to automatically solve conflicts of synchronization between remote Git repositories. fast-forward safe, non-overwriting git fetch or push. non-fast-forward unsafe, forced & overwriting git fetch or push. side directly related one remote and many local git repositories. They are located on one side, i.e. in one company. owner owner of the side. A team that owns and uses their remote repository directly. refs git references, mostly such as branches and tags. conventional refs refs strictly separated by a convention and pertaining to different different sides. Each side owns its refs but can modify refs of another. prefixed refs This is a naming convention and an implementation of conventional refs by prefixes. As an example: " company1/ some_feature ", " company2- develop " where the " company1 / " and " company2 - " are the conventional prefixes. refspec ...
Pure Git Implementation: Pure Git with Convention over Git It uses pure Git techniques. This one is more academic but fully working. Has some limitations. Has the smallest amount of implementation dependencies. *nix & Windows ready. Stateless Analysis Implementation: git-sync The best approach. But it has more implementation dependencies: gawk, modern bash. *nix & Windows ready. Stateful Analysis It depends on collected information about Git refs. It has a wider set of conflict solving tools. Predecessor of all other approaches. Requires a modern software language, an IDE and good programming practices. Implicit Renaming of Refs My beloved. Belongs to the Stateless Analysis. It implies convenient manual conflict solving on the run. It is kinda Git inside the Git with an additional degree of external references.
Comments
Post a Comment