41

I am thinking about starting a small project and I want to make its versioning with git.

Bitbucket seems a good option for me with their free plan. I want to use it as the main tool for working with git since they have nice tools like a web-interface, Mac OS client, and so on. But, in order to have higher protection from any accidental damages that can be caused by using a third-party service, I want also to install git on my NAS as a second back-up copy of the repository.

Now my question is, whether it is possible to create a repository on two different hosts and then keep them in sync? For example, suppose once per week I update the repository on my NAS to match the one on Bitbucket. Then, in case something happens with Bitbucket, I will still have the full repository with full history of development on my local NAS storage.

And is there a way to import an existing repository with full history to another git-service?

I think that mirroring is what I need. This article seems to describe exactly what I need. And this one as well.

I believe that it will make full copy with full history and even automatically commit new versions to the repositories on both hosts automatically.

Am I right?

ChrisF
  • 38,938
BartoNaz
  • 627
  • i am using xpdev i wonder in your 2 system situation what the bennefit would be of rusing git in your case.

    just to be sure from every final build i make a usb backup. But basicly versioning is handled whitin xpdev so its not a real requirement.

    BTW if you own a fool proof NASS Raid1 or so you might consider running your own versioning systems there are some freeones too

     – user613326 Apr 20 '13 at 17:05
  • But I want to have full versioning available in 2 places. If the third-party hosting dies, or the company , running it, just disappears, I want to have exactly the same experience still with all versioning history... – BartoNaz Apr 21 '13 at 09:32
  • It means that I will have Bitbucket for comfort and git on NAS for 99.9% safety. – BartoNaz Apr 21 '13 at 09:44
  • As for xp-dev its unlikely such company dies, they might change code hosting plans, prices, etc.. or merge with another company. But its a money milkcow for them. And they will also backup the valuable data. Its their business to stay in place.

    I use it with 3 developers, and our code exists at 5 different machines, where there is always a local source copy that gets synced at xp dev.

    XP dev is free if you have only a few projects.

     – user613326 Apr 21 '13 at 17:12
  • 1
    Of course, it's unlikely. But still, you can never be 100% sure... – BartoNaz Apr 21 '13 at 19:06
  • the main difference with gitt is that you got a local versioning system where is with xpdev its remote. the Latest version with xpdev is always local after you sync from xpdev – user613326 Apr 23 '13 at 17:48
  • Only once per week??? I want all my repos to be in sync at all times! – Michael Jun 10 '17 at 18:13
  • It sounds like you will have three copies in total - the one on your computer where you do the work, bitbucket, and your NAS. Is there any reason you want to copy from bitbucket to your NAS rather than using the NAS to backup your computer? – bdsl Nov 09 '18 at 08:10
  • git-repo-sync makes the two remote Git-repositories behaving as a single repository. But it doesn't sync Git-tags for some reasons, now. If your are working from one side or for yourself only then you'll never bother a notion of a supervisor, sync strategies and other stuff. This tool is more for indeed independent teams of developers working from different repositories and wanted to have their work synchronized on both sides. But it's really doing what you've asked. – it3xl Feb 23 '21 at 20:48

3 Answers3

21

Yes, that's exactly the beauty of DVCS such as git. You can use any number of different repos with the same state as the one on bitbucket or github.

Even you local copy (the repository on your computer) is usually a full clone of the remote repo.

The only thing you have to do to keep multiple repos in sync is pulling for one (usually called origin or upstream) and pushing to the backup copies.

Wilbert
  • 1,703
  • 1
  • 12
  • 16
  • 12
    Unfortunately all is not as shiny. See the cautionary take of KDE near-disaster. That is, make sure the backup does not delete things (branches, repositories, etc.) that were deleted on the backed up server. – Jan Hudec Apr 19 '13 at 14:04
  • I am still not sure if I understand it correctly. As far as I understand, pushing and pulling works with a certain version. But let's say I have a recent version of the code on my working machine. I have the git repository on the remote host (Bitbucket, Github, or anything else), that has full history of the code development up to the most recent version that I have on the working machine (if it was committed). And I have a repository on the NAS that is empty. Can I import the full history of the code from remote host to my NAS so that I have two identical repositories in two places, and how? – BartoNaz Apr 21 '13 at 19:14
  • 2
    Clone the remote repository, then pull all updates (all branches) to it in regular intervals. A git clone contains the history, it's not like an svn checkout that has only the latest version. – Wilbert Apr 22 '13 at 08:25
14

Here's a tested solution for the issue: Automatic Sync 2 Remote Git Repositories

A simple script for synching 2 remote Git repositories

I've searched the web for a simple script that will sync. 2 remote repositories but I couldn't find such script even that many seems to look for it! So I've created 2 simple test repositories and started testing and building such script.

What such script should do?

Well, in general, the steps for doing it are simple:

  1. Clone the first repository
  2. Add the second one as an additional remote repository
  3. Fetch all there is in the second repository
  4. Push the updated local repository onto the 2 remote repositories.

The remained issue is - what are the correct switches for all the above git commands?

So here it is...

2repos-sync.sh gisp script

# Clear the folder first - please use this carefully
rm -rf $REPO_NAME  
# clone the reposotory
git clone --bare $ORIGIN_URL

# add a remote repository
cd $REPO_NAME
git remote add --mirror=fetch repo1 $REPO1_URL

# update the local copy from the first repository
git fetch origin --tags

# update the local copy with the second repository
git fetch repo1 --tags

# sync back the 2 repositories
git push origin --all
git push origin --tags
git push repo1 --all
git push repo1 --tags

NOTE - this script is not solving cases of conflicts between the repository content!

Community
  • 1
yorammi
  • 241
  • 2
    You might want to mention in your answer that the first thing you do is delete an existing local directory with $REPO_NAME. This seems important and might prevent data loss for people who simply copy your solution. – Wilbert Dec 08 '15 at 15:14
  • To go along with this, LibGit2 is useful for this kind of thing. – RubberDuck Mar 08 '16 at 10:30
0

I use a private GitLab to store all my repositories, so I only have one origin I push and pull from while I'm doing day to day development.

But, for open source projects, GitHub is a much more vibrant community, so, if I want to accept community contributions to my projects, I use web GitLab's web hook system to ping a server I run which then updates my public repos on GitHub.

This allows me to treat GitHub as another remote I can pull from when someone contributes--then I merge --no-ff locally, and there's a flow to how all my primary and public repositories distribute the changes.

diffalot
  • 1