git bundle will only package references that are shown by git show-ref: this includes heads, tags, and remote heads.
It is very important that the basis used be held by the destination.
It is okay to err on the side of caution, causing the bundle file to contain objects already in the destination, as these are ignored when unpacking at the destination.
For using that bundle, you can clone it, specifying a non-existent folder (outside of any git repo):
If you only want to backup project files (without history), you can use git archive (that way, I do not have to "watch for hidden file")
The script git-archive-all.sh will actually archive all git repositories and submodules in the current path.
Useful for creating a single tarfile of a git super-project that contains other submodules.
As Charles Bailey rightly mentions in the comments, git bundle is more appropriate, to preserve the history. (git bundle was introduced in February 2007).
git bundle was designed to allow transfer of git commits when there is no direct connection between repositories (i.e.: offline) but using patches is not an option because of the large number of commits and multiple branches.
A git bundle is just one file which can be very easily created and again imported as it can be treated like another remote. A quick example:
jojo@dualtron:~/devel$ git bundle create ~/devel.bdl master test
and a bundle is saved under ~/devel.bdl containing my master and test branches.
If I am now at repository B I just use jojo@dualtron:~$ git ls-remote devel.bdl which shows me the branches stored in the bundle.
To use the bundle I simple treat it like a remote, using git fetch (for example)
Best Answer
I like that method, as it results in only one file, easier to copy around.
See ProGit: little bundle of joy.
See also "How can I email someone a git repository?", where the command
is detailed:
For using that bundle, you can clone it, specifying a non-existent folder (outside of any git repo):