Stateless Analysis

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.

Saturday, September 30, 2017

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.

After a synchronization interval do "git fetch" and check your
merge-commit is still there.

If not, then just repeat everything.

This is not a problem, really. Your local Git repository always preserves all local branches (it even stores deleted commits in the Git's reflog).

Commits between different sides may disappear if somebody else do a "git push" to the same branch before you.
There is an auto conflict resolving that deletes your merge-commit only in a case of non-fast-forward differences. This is not so often.

By a merge or cherry-pick at another side.
Nobody doing so :-)
This works if your can connect to a remote Git repository of the other side.
Wait the sinсhronization interval and your commits will appear on the remote repository of the other side.
Do a merge between branches there.
Now this is safe. No checks, no worries. Done.

By a plain commit on your side to an other side ref.
Junior developers doing so. Prevent this.
If you feel lucky you can
do a plain commit directly to a branch of the other side.
Again, you must recheck you commit is still there
after a synchronization interval.
And if you're unlucky then you'll end up
searching your commit in the Git-reflog. It is time wasting operation. I warned you.
So, be careful or inform guys on the other side.

Out of convention refs

In the provided implementation mode of the Convention over Git, the sides only see conventional (prefixed) refs.
Not-prefixed branches and tags will stay undisclosed for other sides. They even can have the same names on different remote Git repositories.

Naming convention
Convention over Git uses any naming convention that allows to define owners of each Git-branch.

As an example the prefixed names.
Each remote Git repository owns its prefix and all non-fast-forward conflicts will be solved in favor of a prefix owner.Examplescompany1/develop, company2-developcompany1/JIRA-123, company2-JIRA-321So, the naming convention in Git can be any conventional separation of names

Some defined prefixes or suffixes on both repositories.

A slave repository can have a prefix and a master repository have nothing. I.e. all non conventional (non-prefixed) branches belongs to the master Git-repository

etc

Results

Conventions over Git gives many advantages and drastically simplifies any implementation.

Possibly it is unclear at first glance, but it's worth it.

Please, do not migrate everything between repositories. It is absolutely not necessary and even harmful! CoG just allows to save your repositories in sanity.

GoG adds some level of self responsibility and implies some self management. You shouldn't control everything. Believe in your teams.

All-in-one working implementation

You can test an all-in-one implementation in a project that have I published on GitHub.
It creates local and remote repositories in the project folder, so you can easily emulate and play with Convention over Git on your own.