The beauty of git is that there is no such thing as a central repository, so there is no real concern when any one node goes down. Unfortunately, a common set up for git usage is to use a “central” origin as a remote bare repository from which many developers push/pull.

But even in this case the central bare repo can be competely restored from a local repo. I ran into such a case when the central repo was complete wiped out due to a hard-disk failure. When the system was brought back up, there was obviously no data intact:

$ git push
fatal: '~/git/repo.git' does not appear to be a git repository

Doh. But, no worries, we can just recreate the remote repo:

$ ssh remote.com
$ mkdir git/repo.git && cd git/repo.git
$ git --bare init
Initialized empty Git repository in git/repo.git
$ exit

At this point, it would be nice if git autodetected that the origin was slightly wonky and auto-recover, but it doesn’t seem to:

$ git push
No refs in common and none specified; doing nothing.
Perhaps you should specify a branch such as 'master'.
fatal: The remote end hung up unexpectedly
error: failed to push some refs to 'ssh://remote.com:~/git/repo.git'

However, forcing a copy of all local refs to the remote bare repo does the trick:

$ git push --all

It might take a while, but now your bare remote repo is up and running. In fact, other developers can now push new changes or pull old changes as if nothing had happened!

No tags