Initialize a remote git repository

So you create a git repository (repo) on your local machine (foo) and begin hacking away. Then, you want to push a backup copy of that repo to another box (bar). What’s the best way to do that? There are many ways to do it, but some ways are dangerous and some are just cumbersome.

Ideally, git would have an option to push that instructs it to initialize the remote repository and just do the right thing. I hope this is in our future, but for now we have to do some dancing around.

The canonical way is
bar:~/repo$ git clone --mirror local:repo
...
foo:~/repo$ git push bar:repo --mirror
but that’s not always feasible due to firewalls and nasty NATs.

Unwise methods include copying the working tree with rsync or scp, doing something like the above without --bare or --mirror (which implies --bare), and other methods that would have you pushing to a non-bare repository.

The best method I’ve found is this:
bar:~$ git --git-dir=repo init --bare
foo:~/repo$ git remote add --mirror bar bar:repo
foo:~/repo$ git push bar
...

We set up a bare repository on bar, then set up a “remote” for bar which automatically mirrors (you could do that with the canonical method described above too), so it sends the whole shebang. After that, we push as we normally would.

Tags: , , , , , , , ,

This entry was posted on Thursday, February 12th, 2009 at 18:12. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

6 Responses to “Initialize a remote git repository”

  • philip Says:
    February 14th, 2009 at 08:57

    Ok read it.

    Interesting…. but …. I’m going to go back to Subversion. I *think* git is good for smart people who know what they are doing and are reasonably independent, junior programmers are going to struggle with it, branching is difficult even for most junior programmers to handle.

    I have to write software with senior and junior programmers, so I’m going to go for the lowest common denominator.

  • Jon Says:
    March 1st, 2009 at 23:17

    Subversion might seem easy at first, and branching in git might not be intuitive to new users. But the difference in being able to merge branches is like night and day between svn and git. Doing any sort of non-trivial branch collapse in svn is way beyond a junior programmer’s abilities and they are more likely to create bugs or lose changes than successfully complete an svn merge. Merging in git is relatively painless compared to the other systems I’ve used (cvs, svn, p4, clearcase).
    The draw to svn is that everything is a directory, but given that junior programmers almost never attempt to branch I think this feature is overrated. tags are better in CVS than in svn. and both tags and branches are fairly simple in git, once you let go of the idea that encoding all meta data into an URL is not the best approach.

  • piotr Says:
    April 3rd, 2009 at 20:17

    I’m getting error “not a valid remote name” after “git remote add –mirror …” Can you give examples of valid ones?

  • piotr Says:
    April 3rd, 2009 at 20:23

    OK, read the man page. Anyway, it’s misleading when you write bar bar:repo

  • Hans Says:
    April 3rd, 2009 at 20:24

    Any valid remote repository. For example, if you have a github project it might be “git remote add –mirror foo git@github.com:mygithubusername/mygithubproject.git”

  • Hans Says:
    April 3rd, 2009 at 20:29

    You can call it whatever you want, the name of the host is a logical name. You could write “git remote add –mirror repo_on_bar bar:repo”

Leave a Reply