Automatically keep a secondary repo in sync with a primary repo?

问题

We have a two tier setup.

We have a primary repository (called 'primary' below).

And a secondary repository (called 'secondary' below) that was created like so:

$ git clone --bare --shared $REPO_A/primary secondary.git

People working on the secondary repository view the branches which originated from the primary repository as read only but base their own branches off these branches.

We want to sync up the secondary repository with the primary repository once a day.

I.e. we want commits and new branches that were pushed to the primary to become visible to people working off the secondary repository (next time they do a pull).

We do not want this to be symmetric, i.e. activity against the secondary repository will not become visible to those working off the primary repository.

Ideally I'd like to run a cron job that runs on the machine with the bare secondary repository that somehow fetches new data from the primary and automatically includes it into the secondary.

I was hoping there might be a simple way to do this (and I'm hoping someone here will tell me there is).

If I were to write a script to do it, it would do:

• Create a fresh clone of the secondary.

  $ git clone $REPO_B/secondary
  $ cd secondary
  

• Get all its branches.

  $ git branch -r | sed 's?.*origin/??'
  

• Get all branches in the primary repo.

  $ git ls-remote --heads $REPO_A/primary | sed 's?.*refs/heads/??'
  

• For each primary branch for which I don't already have a corresponding secondary branch:

  $ git fetch $REPO_A/primary $BRANCHNAME:$BRANCHNAME
  $ git push origin $BRANCHNAME:refs/heads/$BRANCHNAME
  

• For each primary branch for which I already have a corresponding secondary branch:

  $ git checkout -b $BRANCHNAME --track origin/$BRANCHNAME
  $ git pull $REPO_A/primary $BRANCHNAME
  $ git push
  

As I'm new to git I wouldn't be surprised if I've failed to consider certain fundamental issues?

And like I said I'm hoping there's a simpler way of doing this, i.e. someone goes "oh, don't do all that, just do...".

回答1:

Oh, don't do all that, just do:

git --bare fetch

;)

(See this old thread for instance)
If you have added the relevant remote origins to your bare repo, you can fetch in turn each of those origins.

回答2:

You can just do a git clone --bare --mirror and periodically do a git fetch to make this happen.

I do it realtimish using a tool called gitmirror I wrote in node.js that I run on a machine at home to receive webhooks from github as well as ad-hoc hooks to sync up commits.

For a non-github example, I have a repo that's used for a couchdb backup that has a commit about once an hour. The cron job basically comes down to this:

# do some backup stuff
git commit -qam "Backup `date`" >> dump.log 2>&1

From there, I have a post-commit hook (.git/hooks/post-commit) that looks like this:

#!/bin/sh
curl -sS http://my.home.machine/gitmirror/bak/repo-name.git

You can accomplish the same thing by pushing from the receiving side. This has the advantage of firing-and-forgetting the payload in the normal case.

回答3:

I would like to see this as a standard Git tool. But these cases are rare. More often it means that there are some limitation in you environment.

I've created a couple of tools for this problem and one of them covers my needs.

But I have to warn that these tools require some knowledge and experience.
My documentation is poor as it fits only my needs and I have no a community to respond right. Sorry for that. Do not waste your time, as you really have to invest your time into it.

gitSync - to just install (it is tough) and use.
convention-over-git - you can catch ideas from here and write you own scripts or a tool.

But nonetheless, gytSync realy solves the problem for me.
I've created gitSync in 2017. We use it all the time and everything is perfect.
Yeah, I fixed a couple of bugs))

gitSync synchronizes git-branches between any two remote git-repositories over HTTP.
Synchronized branches should follow a naming convention.

The naming convention is described in my blog Convention over Git. (I've invented the convention before I've created gitSync.)

Your teams may even work on the same synchronized Git-branch. No problems at all.
It is because gitSync has automated conflict solving.
See details in Git-conflicts solving because you may have to re-commit your changes in case of conflicts.
Indeed I connect different email notifications to gitSync as it exports different run states to files.

Because of automated conflict solving, anybody can do Git-merging in both remote repositories on any synchronized branch and it will be synchronized.
This means that if only one of your teams are capable to do Git-merging or conflict solving then they will do it successfully for both repositories from any repository.

gitSync even has protections from occasional Git-repository wiping.

gitSync tool is resilient for network, IO, and OS troubles. By virtue of Git itself and by couple of my ideas implemented in gitSync. I put it in an architecture before I even have created gitSync. And this was proved by a continued use.

I run gitSymc by different crons, by PowerShell Scheduled Jobs, by Automation Serves (Jenkins, etc.) and manually.

来源：https://stackoverflow.com/questions/3669636/automatically-keep-a-secondary-repo-in-sync-with-a-primary-repo