59

Suppose I have cloned a Git repository to my local disk using:

git clone username@git.example.com:someproject.git

Now suppose that git.example.com is not being backed up, and it goes down in a blaze of glory. Does my clone contain everything necessary to rebuild the remote repo that was lost? The Ultimate Backups section of Git Magic suggests that the answer is "yes," but it isn't clear to me.

Note that I'm not asking "is my local clone a sufficient backup of the master branch?" I'm asking whether my local clone can be considered a complete backup of everything that was contained in the remote repo; all branches, all tags, everything. For example, what about remote branches that aren't tracked in the local repo?

To futher confuse the issue, the existence of git clone --mirror suggests to me that my local clone should not be considered a complete backup of the remote repo.

Matt
  • 2,187
  • 1
  • 16
  • 23
  • 4
    I would say that the existence of `clone --mirror` *clarifies* the issue. The things that a mirror clone copies which a normal bare clone doesn't are precisely what makes the normal clone an incomplete backup. If that's not clear to you, you could try [this question](http://stackoverflow.com/questions/3959924/whats-the-difference-between-git-clone-mirror-and-git-clone-bare/3960063#3960063). – Cascabel Jan 11 '11 at 14:45
  • 1
    i know it's a 30 year old comment but... @Cascabel implicit < explicit. – Cory Mawhorter Jul 31 '18 at 17:48

3 Answers3

57

A clone can be considered a full backup of all the data in your remote repository, but not necessarily the meta-data (that's where the --mirror switch comes in). Your clone will contain all the commit, tree, blob, branch, and tag objects that are in any way referenced by the repository. That means your backup will contain all your source code, history, and associated branches or tags.

The difference with the --mirror switch is that without it, the clone won't include things like remotes that have been created on the server. These are not important in a "I hope I haven't lost any source!" kind of way, but they may be for getting your server back up and running like it was.

If you're interested in creating a backup that can be restored onto the server like there was never any issue, then you should use --mirror, but for most scenarios a simple clone is fine.

James Gregory
  • 14,173
  • 2
  • 42
  • 60
  • Updated my answer after doing more research on `--mirror` – James Gregory Jan 11 '11 at 14:36
  • Thanks for the answer. I should clarify that the repository cloned is a bare repository, and I don't expect it to ever have remotes. Until the system containing the bare repository is set up for backups, I will be relying on my clone (which IS being backed up with CrashPlan) in a disaster scenario. Based on your answer, I now feel comfortable doing so. – Matt Jan 11 '11 at 17:55
8

IMPORTANT

Without --mirror, The clone will not be a complete backup. Any line of work not visible in git branch -r will be elided from the clone.

Simple Demo

Witness a simple repo.

$ git init G
$ cd G
$ for f in 1 2 3 4; do date >1 && git add 1 && git commit -m $f; sleep 1.1; done
$ git log --oneline --graph --all --decorate
* 3c111bd (HEAD -> master) 4
* a08fea4 3
* d5c8d73 2
* 802856b 1

Add a branch:

$ git checkout d5c8d73
HEAD is now at d5c8d73... 2
$ git branch starts-at-2
$ git checkout starts-at-2
Switched to branch 'starts-at-2'
$ for f in 1 2 3 4; do date >1 && git add 1 && git commit -m 2-$f; sleep 1.1; done
$ git log --oneline --graph --all --decorate
* 6bb05bf (HEAD -> starts-at-2) 2-4
* fe1b635 2-3
* a9323fb 2-2
* 33502af 2-1
| * 3c111bd (master) 4
| * a08fea4 3
|/
* d5c8d73 2
* 802856b 1

Clone the repo.

$ cd ..
$
$ git clone G G2
Cloning into 'G2'...
$ cd G2
$ git log --oneline --graph --all --decorate
* 6bb05bf (HEAD -> starts-at-2, origin/starts-at-2, origin/HEAD) 2-4
* fe1b635 2-3
* a9323fb 2-2
* 33502af 2-1
| * 3c111bd (origin/master) 4
| * a08fea4 3
|/
* d5c8d73 2
* 802856b 1

Fine. Clone again.

$ cd ..
$ git clone G2 G3
$ cd G3
$ git log --oneline --graph --all --decorate
* 6bb05bf (HEAD -> starts-at-2, origin/starts-at-2, origin/HEAD) 2-4
* fe1b635 2-3
* a9323fb 2-2
* 33502af 2-1
* d5c8d73 2
* 802856b 1

Urk.

bobbogo
  • 14,989
  • 3
  • 48
  • 57
  • Thank-you! This example shows why a simple clone is not sufficient. All of the other answers were filled with git-specific jargon, that while accurate, were not terribly helpful to someone who is not already familiar with git-arcane. "refs, remotes,... and lions and tigers and bears". So, you see. It's all very clear. It wasn't. But, now it is. – A. Rick Dec 22 '20 at 14:39
5

Your local clone won't be a complete backup. It will be a backup of the state of that repository, but it won't have all the refs of the source repository (so it won't know about the state of any remote branches).

For a complete backup, you correctly found git clone --mirror. This will not only have the branches for the original repository. It will also map all refs including remote branches.

Abizern
  • 146,289
  • 39
  • 203
  • 257