开发者

synchronize between 2 git repositories

I have 2 bare repositories. They are made like this:

ssh git@primary.com
git init --bare repo1
ssh git@backup.com
git clone --bare git@primary.com:repo1

One is used for development (let's call it primary) and one is used for backup (in case first is not accessible). Is it possible to automat开发者_如何转开发ically synchronize them - something like doing git pull on backup.

I guess you can't merge or pull on bare repository. Is there another way to have backup repository up to date, rather than this:

ssh git@backup.com
rm repo1 -fr
git clone -- bare git@primary.com:repo1

of course when primary wasn't accessible for a while and I used backup then I would want to update primary.

Also adding 2 remotes to the working repository is a solution, but you have to constantly push to the both of them, which can't happen if one is inaccessible.

All conflicts are resolved in the non-bare repositories

edit why do I need backup repository:

we use remote repository to exchange code and it's needed daily. usually people don't need code written by other developers, but that's not always the case. we lost contact with primary for 3 days and it was not easy to develop. I made second repository on another server and I cloned local, but I had to do that for a lot of projects and it's time consuming. I prefer to have the second repository automatically updated.


You can use git push --mirror other-remote to mirror all the refs in one repository to another. This won't mirror the repository config or stashes, though - you might want to also look at this question's answers:

  • Is "git push --mirror" sufficient for backing up my repository?

Update: In response to your clarified question and comment below, I should say that it's not safe to git push --mirror in both directions, since git push --mirror does a forced update of refs and removes deleted refs. For example, suppose your master on primary is ahead of that on backup and there's a new branch on primary that hasn't been mirrored yet - then a git push --mirror will reset the master branch on primary to an old state and delete the newly created branch.

In addition, even if you're only mirroring from primary to backup, it's not safe to allow people to push to backup, since anything new pushed solely to there would be removed by the next mirror.

So, what can you do? I'm assuming that when the primary repository is unavailable, that whole machine is unavailable. So, on the backup server, I would create one bare repository, as you suggest, that a cron job on primary will mirror the repository to. You shouldn't allow people to push to that mirrored repository, however - when the primary server goes down, clone the mirror to create a bare repository that people can push to in the mean time. When the primary server is back up, stop people from being able to push to that new repository on the backup, then merge the changes from there locally and push the new work back to the primary server.


Use a crontab script or similar to run git push --mirror remote to your backup on a regular basis. You could also add a commit hook to automatically force push to another remote on updates, this way you don't have a "failure window". No need to update from backup since it will presumably never have any new or updated content of it's own.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜