Using Git Bundles for Repository Updates and Backups

clone -b master /home/me/tmp/file.bundle R2 ---------------- This will define a remote called "origin" in the resulting repository that lets you fetch and pull from the bundle. The $GIT_DIR/config file in R2 will have an entry like this: ------------------------ [remote "origin"] url = /home/me/tmp/file.bundle fetch = refs/heads/*:refs/remotes/origin/* ------------------------ To update the resulting mine.git repository, you can fetch or pull after replacing the bundle stored at /home/me/tmp/file.bundle with incremental updates. After working some more in the original repository, you can create an incremental bundle to update the other repository: ---------------- machineA$ cd R1 machineA$ git bundle create file.bundle lastR2bundle..master machineA$ git tag -f lastR2bundle master ---------------- You then transfer the bundle to the other machine to replace /home/me/tmp/file.bundle, and pull from it. ---------------- machineB$ cd R2 machineB$ git pull ---------------- If you know up to what commit the intended recipient repository should have the necessary objects, you can use that knowledge to specify the prerequisites, giving a cut-off point to limit the revisions and objects that go in the resulting bundle. The previous example used the lastR2bundle tag for this purpose, but you can use any other options that you would give to the linkgit:git-log[1] command. Here are more examples: You can use a tag that is present in both: ---------------- $ git bundle create mybundle v1.0.0..master ---------------- You can use a prerequisite based on time: ---------------- $ git bundle create mybundle --since=10.days master ---------------- You can use the number of commits: ---------------- $ git bundle create mybundle -10 master ---------------- You can run `git-bundle verify` to see if you can extract from a bundle that was created with a prerequisite: ---------------- $ git bundle verify mybundle ---------------- This will list what commits you must have in order to extract from the bundle and will error out if you do not have them. A bundle from a recipient repository's point of view is just like a regular repository which it fetches or pulls from. You can, for example, map references when fetching: ---------------- $ git fetch mybundle master:localRef ---------------- You can also see what references it offers: ---------------- $ git ls-remote mybundle ---------------- DISCUSSION ---------- A naive way to make a full backup of a repository is to use something to the effect of `cp -r <repo> <destination>`. This is discouraged since the repository could be written to during the copy operation. In turn some files at `<destination>` could be corrupted. This is why it is recommended to use Git tooling for making repository backups, either with this command or with e.g. linkgit:git-clone[1]. But keep in mind that these tools will not help you backup state other than refs and commits. In other words they will not help you backup contents of the index, working tree, the stash, per-repository configuration, hooks, etc. See also linkgit:gitfaq[7], section "TRANSFERS" for a discussion of the problems associated with file syncing across systems. FILE FORMAT ----------- See linkgit:gitformat-bundle[5]. GIT --- Part of the linkgit:git[1] suite

Git bundles can be used to update a repository by creating an incremental bundle and transferring it to the target machine. The bundle can be verified to ensure it can be extracted, and references can be mapped when fetching. Additionally, Git bundles can be used to make repository backups, but they only backup refs and commits, not other state such as the index, working tree, or configuration. The recommended method for backups is to use Git tooling, such as git-clone or git-bundle, rather than simply copying the repository files.