40

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?

Improve this question
9
  • 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
    Commented Apr 20, 2013 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
    Commented Apr 21, 2013 at 9:32
  • It means that I will have Bitbucket for comfort and git on NAS for 99.9% safety.
    – BartoNaz
    Commented Apr 21, 2013 at 9: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
    Commented Apr 21, 2013 at 17:12
  • 1
    Of course, it's unlikely. But still, you can never be 100% sure...
    – BartoNaz
    Commented Apr 21, 2013 at 19:06

3 Answers 3

Reset to default
20

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.

Improve this answer
3
  • 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
    Commented Apr 19, 2013 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
    Commented Apr 21, 2013 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
    Commented Apr 22, 2013 at 8: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!

Improve this answer
2
  • 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
    Commented Dec 8, 2015 at 15:14
  • To go along with this, LibGit2 is useful for this kind of thing.
    – RubberDuck
    Commented Mar 8, 2016 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.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.