I want to emphasize that git-sync synchronizes Git remote repositories. So, let's use git-repo-sync name instead.

gitSync synchronizes git-branches between remote git-repositories.

Synchronized branches should follow a naming convention.

The naming convention is Convention over Git.

gitSync works over HTTP only. It is because I had no chance to tune it for SSH.

gitSync synchronizes only two remote repositories for simplicity as it is a scripting solution.

gitSync do not synchronize Git-tags anymore. It's because some popular Git-servers block Git-tags deletion.

gitSync has auto conflict solving. That allows to work on the same Git-branch simultaneously.
I.e. you can commit and merge to the same branch on both remote repositories. In case of a conflict you have to repeat your commit. More details on this in Git conflicts solving.

• Auto synchronization of remote Git-repositories.
• Sharing of a repository with limited internet access with your partners.
• Keeping of repositories neat and sane between customers and clients.

If you will run git-sync.sh without parameters, then a test environment will be created.
You will get two remote and two local interconnected repositories on your machine.
Make changes there, run git-sync.sh, see behavour and results.

Imagine, there are two remote repositories. Each repository is a separate side.
You agreed that

• the first repository owns a prefix foo-
• the second repository owns a prefix bar/
• branch names after prefixes are arbitrary.

Only branches with such the prefixes will be synchronized and visible on both sides.

Conflicts may occur only if your do merges or commits to another side branches.
The prefix owner will win in case of any conflicts.
Commits of a loser will be rejected, but he just has to repeat merge or commits again (from his local repository) after a Git update (fetch, pull, etc).

To know if your commit was reflected first run gitSync then do a Git update (fetch, pull, etc) in your local Git repository.
Then look at Git commits log.

I've excluded Git-tags from synchronization. Nothing wrong with tags but there are some nervous subtleties with them.

Why is everything done so? - This is a proven and working solution. But it is also modest and supported by a single person, me.
Why do not synchronize everything at once? - You will spend significant resources to do it professionally.
Is it possible to synchronize all branches and tags? - Yes. I had other solutions and ideas. No one is interested.
Why do not sync Git-tags? - This is disabled because some popular Git-servers block deletion of tags.

Most of the following sections describe technical details.
if you are technically savvy, I expect you will complete everything from one day to one week. Depends on your situation and needs.
The only thing I want to say, this is really working.
I am waiting for your notes and wish you luck.

Ask me. I'll answer on you questions ASAP.
See my contacts at it3xl.ru.

• Prevention of an occasional deletion of an entire repository.
• Deletion and creation of branches from one side repository to another.
• Auto conflict solving by Convention over Git (non-fast-forward branch conflicts).
• Recreation of the synchronization from any position and from scratch.
• Failover & auto recovery of synchronization is supported. Especially for network troubles.
• Solution is applied per-repository (not per-server)
• Synchronization of the Git-tags was removed because GitLab loves to block tag's deletion.
• Single non-bare Git repository is used for the synchronization.
• You can attach your automations to notify about conflict solving or a branch deletion.

I use my bash Git Credential Helper git-cred
It passes to Git credentials from enviroment variables created by Continues Intergration tools like Jenkins.
It is inegrated now with git-sync.

Victim Branches

I've temporary postponed this feature. Everybody can live without it. Although it is annoying.

We have some branches that reflect all our stands (dev, test, UAT, pre-prod).
Any commit three runs complete CI/CD processes.
It is useful to allow any team sides to put this branches at any position, on any commit.
I think it is time to add such branches into git-sync.

E.g.
victim/test-stand
victim-test-stand

Here is my glossary related to the topic.

You need to describe the prefixes and simple details of your real remote repositories in a simple config-file.
Create the same file as your_repo_some_name.sh.

Run the git-sync and pass a path to your config file as a parameter.

bash git-sync.sh "relative_or_absolute_path/project_settings.sh"

Run git-sync so periodically, better once in a minute.

That's all. You may work and forget about git-sync.
In the case of any synchronization interruption git-sync will do everything right.

Use any *nix or Window machine.

Install Git

For *nix users - update you bash and awk to any modern version

Tune any automation to invocate git-sync periodically - crons, schedulers, Jenkins, GitLab-CI, etc.