Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I am planning to switch from SVN to git. With svn I just copy my repo folder when I want to back it up. However git doesn't have one so what do I do?

Should I create a clone on a separate drive and update by pulling from my project? Then I can burn/archive this folder and it will have all the history?

This is probably obvious but I want to make sure when it comes to backups. I still pretend there is a root repository.

share|improve this question
    
See also: Backup a GitHub repository (the answers work for non-GitHub git projects, too) –  moose Oct 29 at 11:45

5 Answers 5

up vote 8 down vote accepted

You just copy it. git does use a repo folder, it's just hidden from normal directory views. (The folder is named .git on *nix systems, so it only appears if you use ls -a. I assume that it sets the "hidden" attribute in Windows, but I've never used git in a Windows environment, so I'm not certain about how it's handled there.)

share|improve this answer
    
Theres a couple project files in my trunk i ignore. So i literally can copy it? (i'll assume it works the same way as linux). So is clone just a file copy? i guess if i pull all the data i want is in the folder. I checked there are .git files but there are .svn files in my svn trunk and didnt think to check if history data was in there –  acidzombie24 Dec 8 '10 at 11:32
1  
On Windows, it's still .git, with the "Hidden" attribute. –  grawity Dec 8 '10 at 12:25
1  
@acidzombie24: The .git directory contains the entire repository state, including the history. (That's the "distributed" part.) –  grawity Dec 8 '10 at 12:27
5  
@grawity: its more the "selfcontained" part, the distributed part is when you exchange diffs between the selfcontained repositories :) –  akira Dec 8 '10 at 12:49

The akira answer is correct, but you can add --mirror to create a bare repo (for a slightly smaller backup).

We use the following strategy (almost exactly):

git clone --mirror yourrepo backup.repo
tar cjf backup.repo.tar.bz2 backup.repo
scp backup.tar.bz2 ssh://somewhereelse

Then, to recover from your backup:

tar xjf backup.repo.tar.bz2
git clone backup.repo yourrepo
share|improve this answer
1  
This is helpful, thanks. How do I use the backed-up repo to restore the working tree? –  Jonathan Day Nov 7 '11 at 11:49

Im using bundle. For making a copy file (one backup file) execute:

git bundle create backup.bundle master

For restoring repository with branch master simple clone file backup.bundle

git clone backup.bundle -b master my-project
share|improve this answer

create a new clone somewhere else:

 % git clone yourepo somewhereelse

btw, git has a repo folder, you can locate it in your working copy underneath the subdirectory .git. every working copy has that "repo folder".

share|improve this answer
    
+1 and i nearly accept this –  acidzombie24 Dec 8 '10 at 14:50
7  
I do not think a clone is acceptable as a backup, as it is not an exact copy. At least the remote branches of the cloned repo will be missing in the clone, and the branches of the cloned repo will appear as remote branches in the clone. –  sleske Nov 2 '11 at 19:36

Should be pointed out for the record, especially for new Git users (and considering OP's comment above: "Theres a couple project files in my trunk i ignore.", or another comment: "How do I use the backed-up repo to restore the working tree?"), that:

  • one thing is the Git "repo", and
  • another thing is your actual project dir (or workspace etc.), which is the Git repo + the "work tree" (i.e. all other files you may still need, like precious login credentials, not in the repo!)

In many actual backup (and especially migration) cases the actual focus is not just on the repo itself, but on all the "project stuff", which is both the Git repo, and all the other work files, either checked in to the Git repo or not (being ".gitignored").

For these cases (where the whole project workspace is to be replicated), the only correct procedure seems to be copying the whole project dir tree (including, but not limited to the Git repo).

(The accepted answer said that, but didn't explain why it would actually be the preferred way: this can be a life-saver when restoring the backup a year later only to see the checked-in master branch and nothing else, which cannot be built, tested, deployed, or even opened in an IDE, without all the "ignored" work-tree files.)

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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