#it3xl

(draft, thoughts) Every Git repository is a separate universe. I mean, even your local repository may be considered as a primary remote repository at any time. So, how to merge two universes? By force, coercion and fire? Nope, USA is not applicable here, we always lose valuable pieces of work (world) in such a way. CoG Convention over Git approach is arising here. First you agree to only sync branches under a naming convention. You allow to push commits to your side repo freely and automatically until they do not conflict with yours. If they conflict, another side is free to do, say, a Git-rebase and retry. CoG deals with and separates notions of Non Fast Forward and Fast Forward commits of Git. See CoG link, to take it deeper. To recap, you are in an awkward position with your wishes, because this kind of things is uncommon in the Git world and is not researched well. That's all. Have questions?

It is an implementation of remote Git repositories synchronization by the  pure Git and the Convention over Git . This approach uses well-known Git tools, because Git has an innate ability to do such synchronizations. All we need to add to Git is some convention. (Consider to use git-sinc , the next generation of remote Git repositories synchronization.) The situation Say, we have teams in separate companies. Each team owns their own repository hosted on their own separate git server. This often happens for vendor-client scenarios. The targets Create a single force, a single team. Eliminate severe and constant errors as a result of disunity. Eliminate significant time wasting. No single repository, no team's heart beating. P.S.: I even call this approach as Conventional Distributed Version Control System over Git.

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.

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 ...

This page explains how to use the Pure Git with Convention over Git  solution to synchronize Git remote repositories. Or how to live with Git remote repositories auto synchronized by it. But consider to use  git-sinc , the next generation of remote Git repositories synchronization. How to work with the Convention over Git Use Git, as you always do, except for the following. Name branches and tags with a prefix of your side (as an example " company/ some_branch_name "). Do plain commits to prefixed branches of your side. Delete only branches and tags of your side. Deleted by you refs from other sides will be recreated automatically. How to migrate your work to another side refs All refs will be updated on all sides automatically. But when you will want to migrate your work to another side, you will do one of the following. By a merge or cherry-pick from your side Do a plain merge from you prefixed branch to a prefixed branch of another side. ...

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 ...

This is a cheat-sheet for a simplest implementation of the Convention over Git  and of the  pure Git and the Convention over Git . This is used for an automated synchronization between remote Git repositories. (Consider to use  git-sinc , the next generation of remote Git repositories synchronization.) If you understand the idea of the Convention over Git , then it is easier to look at this cheat-sheet. Otherwise look at the Convention over Git  article and on the project's home page . Here we'll start. Let's say some two development teams in companies "A -1 " and "B -2 " want to auto-synchronize a Git-repository named " repo " with each other. We have some preconditions: The teams want to synchronize only conventionally named branches. Not the entire repository, which is also possible. GitLab of one of the teams automatically blocks tags deletion. So, they decided to exclude Git-tags from syncing. Guys have no time for optimizati...