Git User's Manual (for version 1.5.1 or newer)

It will be useful to have a git repository to experiment with as you read this manual.

The best way to get one is by using the git-clone(1) command to download a copy of an existing repository for a project that you are interested in. If you don't already have a project in mind, here are some interesting examples:

The initial clone may be time-consuming for a large project, but you will only need to clone once.

The clone command creates a new directory named after the project ("git" or "linux-2.6" in the examples above). After you cd into this directory, you will see that it contains a copy of the project files, together with a special top-level directory named ".git", which contains all the information about the history of the project.

In most of the following, examples will be taken from one of the two repositories above.

Git is best thought of as a tool for storing the history of a collection of files. It stores the history as a compressed collection of interrelated snapshots (versions) of the project's contents.

A single git repository may contain multiple branches. It keeps track of them by keeping a list of heads which reference the latest version on each branch; the git-branch(1) command shows you the list of branch heads:

A freshly cloned repository contains a single branch head, by default named "master", with the working directory initialized to the state of the project referred to by that branch head.

Most projects also use tags. Tags, like heads, are references into the project's history, and can be listed using the git-tag(1) command:

Tags are expected to always point at the same version of a project, while heads are expected to advance as development progresses.

Create a new branch head pointing to one of these versions and check it out using git-checkout(1):

The working directory then reflects the contents that the project had when it was tagged v2.6.13, and git-branch(1) shows two branches, with an asterisk marking the currently checked-out branch:

If you decide that you'd rather see version 2.6.17, you can modify the current branch to point at v2.6.17 instead, with

Note that if the current branch head was your only reference to a particular point in history, then resetting that branch may leave you with no way to find the history it used to point to; so use this command carefully.

Every change in the history of a project is represented by a commit. The git-show(1) command shows the most recent commit on the current branch:

As you can see, a commit shows who made the latest change, what they did, and why.

Every commit has a 40-hexdigit id, sometimes called the "object name" or the "SHA1 id", shown on the first line of the "git show" output. You can usually refer to a commit by a shorter name, such as a tag or a branch name, but this longer name can also be useful. Most importantly, it is a globally unique name for this commit: so if you tell somebody else the object name (for example in email), then you are guaranteed that name will refer to the same commit in their repository that it does in yours (assuming their repository has that commit at all). Since the object name is computed as a hash over the contents of the commit, you are guaranteed that the commit can never change without its name also changing.

In fact, in Chapter 7, Git internals we shall see that everything stored in git history, including file data and directory contents, is stored in an object with a name that is a hash of its contents.

         o--o--o <-- Branch A
        /
 o--o--o <-- master
        \
         o--o--o <-- Branch B

Creating, deleting, and modifying branches is quick and easy; here's a summary of the commands:

The special symbol "HEAD" can always be used to refer to the current branch. In fact, git uses a file named "HEAD" in the .git directory to remember which branch is current:

The git-checkout command normally expects a branch head, but will also accept an arbitrary commit; for example, you can check out the commit referenced by a tag:

The HEAD then refers to the SHA1 of the commit instead of to a branch, and git branch shows that you are no longer on a branch:

In this case we say that the HEAD is "detached".

This is an easy way to check out a particular version without having to make up a name for the new branch. You can still create a new branch (or tag) for this version later if you decide to.

The "master" branch that was created at the time you cloned is a copy of the HEAD in the repository that you cloned from. That repository may also have had other branches, though, and your local repository keeps branches which track each of those remote branches, which you can view using the "-r" option to git-branch(1):

You cannot check out these remote-tracking branches, but you can examine them on a branch of your own, just as you would a tag:

Note that the name "origin" is just the name that git uses by default to refer to the repository that you cloned from.

Branches, remote-tracking branches, and tags are all references to commits. All references are named with a slash-separated path name starting with "refs"; the names we've been using so far are actually shorthand:

The full name is occasionally useful if, for example, there ever exists a tag and a branch with the same name.

As another useful shortcut, the "HEAD" of a repository can be referred to just using the name of that repository. So, for example, "origin" is usually a shortcut for the HEAD branch in the repository "origin".

For the complete list of paths which git checks for references, and the order it uses to decide which to choose when there are multiple references with the same shorthand name, see the "SPECIFYING REVISIONS" section of git-rev-parse(1).

Eventually the developer cloned from will do additional work in her repository, creating new commits and advancing the branches to point at the new commits.

The command "git fetch", with no arguments, will update all of the remote-tracking branches to the latest version found in her repository. It will not touch any of your own branches—not even the "master" branch that was created for you on clone.

You can also track branches from repositories other than the one you cloned from, using git-remote(1):

New remote-tracking branches will be stored under the shorthand name that you gave "git remote add", in this case linux-nfs:

If you run "git fetch <remote>" later, the tracking branches for the named <remote> will be updated.

If you examine the file .git/config, you will see that git has added a new stanza:

This is what causes git to track the remote's branches; you may modify or delete these configuration options by editing .git/config with a text editor. (See the "CONFIGURATION FILE" section of git-config(1) for details.)

Suppose version 2.6.18 of your project worked, but the version at "master" crashes. Sometimes the best way to find the cause of such a regression is to perform a brute-force search through the project's history to find the particular commit that caused the problem. The git-bisect(1) command can help you do this:

If you run "git branch" at this point, you'll see that git has temporarily moved you to a new branch named "bisect". This branch points to a commit (with commit id 65934…) that is reachable from v2.6.19 but not from v2.6.18. Compile and test it, and see whether it crashes. Assume it does crash. Then:

checks out an older version. Continue like this, telling git at each stage whether the version it gives you is good or bad, and notice that the number of revisions left to test is cut approximately in half each time.

After about 13 tests (in this case), it will output the commit id of the guilty commit. You can then examine the commit with git-show(1), find out who wrote it, and mail them your bug report with the commit id. Finally, run

to return you to the branch you were on before and delete the temporary "bisect" branch.

Note that the version which git-bisect checks out for you at each point is just a suggestion, and you're free to try a different version if you think it would be a good idea. For example, occasionally you may land on a commit that broke something unrelated; run

which will run gitk and label the commit it chose with a marker that says "bisect". Chose a safe-looking commit nearby, note its commit id, and check it out with:

then test, run "bisect good" or "bisect bad" as appropriate, and continue.

We have seen several ways of naming commits already:

There are many more; see the "SPECIFYING REVISIONS" section of the git-rev-parse(1) man page for the complete list of ways to name revisions. Some examples:

Recall that merge commits may have more than one parent; by default, ^ and ~ follow the first parent listed in the commit, but you can also choose:

In addition to HEAD, there are several other special names for commits:

Merges (to be discussed later), as well as operations such as git-reset, which change the currently checked-out commit, generally set ORIG_HEAD to the value HEAD had before the current operation.

The git-fetch operation always stores the head of the last fetched branch in FETCH_HEAD. For example, if you run git fetch without specifying a local branch as the target of the operation

the fetched commits will still be available from FETCH_HEAD.

When we discuss merges we'll also see the special name MERGE_HEAD, which refers to the other branch that we're merging in to the current branch.

The git-rev-parse(1) command is a low-level command that is occasionally useful for translating some name for a commit to the object name for that commit:

We can also create a tag to refer to a particular commit; after running

You can use stable-1 to refer to the commit 1b2e1d63ff.

This creates a "lightweight" tag. If you would also like to include a comment with the tag, and possibly sign it cryptographically, then you should create a tag object instead; see the git-tag(1) man page for details.

The git-log(1) command can show lists of commits. On its own, it shows all commits reachable from the parent commit; but you can also make more specific requests:

And of course you can combine all of these; the following finds commits since v2.5 which touch the Makefile or any file under fs:

You can also ask git log to show patches:

See the "—pretty" option in the git-log(1) man page for more display options.

Note that git log starts with the most recent commit and works backwards through the parents; however, since git history can contain multiple independent lines of development, the particular order that commits are listed in may be somewhat arbitrary.

You can generate diffs between any two versions using git-diff(1):

Sometimes what you want instead is a set of patches:

will generate a file with a patch for each commit reachable from test but not from master. Note that if master also has commits which are not reachable from test, then the combined result of these patches will not be the same as the diff produced by the git-diff example.

You can always view an old version of a file by just checking out the correct revision first. But sometimes it is more convenient to be able to view an old version of a single file without checking anything out; this command does that:

Before the colon may be anything that names a commit, and after it may be any path to a file tracked by git.

Somebody hands you a copy of a file, and asks which commits modified a file such that it contained the given content either before or after the commit. You can find out with this:

Figuring out why this works is left as an exercise to the (advanced) student. The git-log(1), git-diff-tree(1), and git-hash-object(1) man pages may prove helpful.

Before creating any commits, you should introduce yourself to git. The easiest way to do so is to make sure the following lines appear in a file named .gitconfig in your home directory:

(See the "CONFIGURATION FILE" section of git-config(1) for details on the configuration file.)

Creating a new repository from scratch is very easy:

If you have some initial content (say, a tarball):

Creating a new commit takes three steps:

In practice, you can interleave and repeat steps 1 and 2 as many times as you want: in order to keep track of what you want committed at step 3, git maintains a snapshot of the tree's contents in a special staging area called "the index."

At the beginning, the content of the index will be identical to that of the HEAD. The command "git diff —cached", which shows the difference between the HEAD and the index, should therefore produce no output at that point.

Modifying the index is easy:

To update the index with the new contents of a modified file, use

To add the contents of a new file to the index, use

To remove a file from the index and from the working tree,

After each step you can verify that

always shows the difference between the HEAD and the index file—this is what you'd commit if you created the commit now—and that

shows the difference between the working tree and the index file.

Note that "git add" always adds just the current contents of a file to the index; further changes to the same file will be ignored unless you run git-add on the file again.

When you're ready, just run

and git will prompt you for a commit message and then create the new commit. Check to make sure it looks like what you expected with

As a special shortcut,

will update the index with any files that you've modified or removed and create a commit, all in one step.

A number of commands are useful for keeping track of what you're about to commit:

Though not required, it's a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. Tools that turn commits into email, for example, use the first line on the Subject line and the rest of the commit in the body.

A project will often generate files that you do not want to track with git. This typically includes files generated by a build process or temporary backup files made by your editor. Of course, not tracking files with git is just a matter of not calling "git add" on them. But it quickly becomes annoying to have these untracked files lying around; e.g. they make "git add ." and "git commit -a" practically useless, and they keep showing up in the output of "git status", etc.

Git therefore provides "exclude patterns" for telling git which files to actively ignore. Exclude patterns are thoroughly explained in the "Exclude Patterns" section of the git-ls-files(1) manual page, but the heart of the concept is simply a list of files which git should ignore. Entries in the list may contain globs to specify multiple files, or may be prefixed by "!" to explicitly include (un-ignore) a previously excluded (ignored) file (i.e. later exclude patterns override earlier ones). The following example should illustrate such patterns:

The next question is where to put these exclude patterns so that git can find them. Git looks for exclude patterns in the following files:

You can rejoin two diverging branches of development using git-merge(1):

merges the development in the branch "branchname" into the current branch. If there are conflicts—for example, if the same file is modified in two different ways in the remote branch and the local branch—then you are warned; the output may look something like this:

Conflict markers are left in the problematic files, and after you resolve the conflicts manually, you can update the index with the contents and run git commit, as you normally would when creating a new file.

If you examine the resulting commit using gitk, you will see that it has two parents, one pointing to the top of the current branch, and one to the top of the other branch.

When a merge isn't resolved automatically, git leaves the index and the working tree in a special state that gives you all the information you need to help resolve the merge.

Files with conflicts are marked specially in the index, so until you resolve the problem and update the index, git-commit(1) will fail:

Also, git-status(1) will list those files as "unmerged", and the files with conflicts will have conflict markers added, like this:

All you need to do is edit the files to resolve the conflicts, and then

Note that the commit message will already be filled in for you with some information about the merge. Normally you can just use this default message unchanged, but you may add additional commentary of your own if desired.

The above is all you need to know to resolve a simple merge. But git also provides more information to help resolve conflicts:

If you get stuck and decide to just give up and throw the whole mess away, you can always return to the pre-merge state with

Or, if you've already commited the merge that you want to throw away,

However, this last command can be dangerous in some cases—never throw away a commit you have already committed if that commit may itself have been merged into another branch, as doing so may confuse further merges.

There is one special case not mentioned above, which is treated differently. Normally, a merge results in a merge commit, with two parents, one pointing at each of the two lines of development that were merged.

However, if the current branch is a descendant of the other—so every commit present in the one is already contained in the other—then git just performs a "fast forward"; the head of the current branch is moved forward to point at the head of the merged-in branch, without any new commits being created.

If you've messed up the working tree, but haven't yet committed your mistake, you can return the entire working tree to the last committed state with

If you make a commit that you later wish you hadn't, there are two fundamentally different ways to fix the problem:

On large repositories, git depends on compression to keep the history information from taking up to much space on disk or in memory.

This compression is not performed automatically. Therefore you should occasionally run git-gc(1):

to recompress the archive. This can be very time-consuming, so you may prefer to run git-gc when you are not doing other work.

After you clone a repository and make a few changes of your own, you may wish to check the original repository for updates and merge them into your own work.

We have already seen how to keep remote tracking branches up to date with git-fetch(1), and how to merge two branches. So you can merge in changes from the original repository's master branch with:

However, the git-pull(1) command provides a way to do this in one step:

In fact, "origin" is normally the default repository to pull from, and the default branch is normally the HEAD of the remote repository, so often you can accomplish the above with just

See the descriptions of the branch.<name>.remote and branch.<name>.merge options in git-config(1) to learn how to control these defaults depending on the current branch. Also note that the —track option to git-branch(1) and git-checkout(1) can be used to automatically set the default remote branch to pull from at the time that a branch is created:

In addition to saving you keystrokes, "git pull" also helps you by producing a default commit message documenting the branch and repository that you pulled from.

(But note that no such commit will be created in the case of a fast forward; instead, your branch will just be updated to point to the latest commit from the upstream branch.)

The git-pull command can also be given "." as the "remote" repository, in which case it just merges in a branch from the current repository; so the commands

are roughly equivalent. The former is actually very commonly used.

If you just have a few changes, the simplest way to submit them may just be to send them as patches in email:

First, use git-format-patch(1); for example:

will produce a numbered series of files in the current directory, one for each patch in the current branch but not in origin/HEAD.

You can then import these into your mail client and send them by hand. However, if you have a lot to send at once, you may prefer to use the git-send-email(1) script to automate the process. Consult the mailing list for your project first to determine how they prefer such patches be handled.

Git also provides a tool called git-am(1) (am stands for "apply mailbox"), for importing such an emailed series of patches. Just save all of the patch-containing messages, in order, into a single mailbox file, say "patches.mbox", then run

Git will apply each patch in order; if any conflicts are found, it will stop, and you can fix the conflicts as described in "Resolving a merge". (The "-3" option tells git to perform a merge; if you would prefer it just to abort and leave your tree and index untouched, you may omit that option.)

Once the index is updated with the results of the conflict resolution, instead of creating a new commit, just run

and git will create the commit for you and continue applying the remaining patches from the mailbox.

The final result will be a series of commits, one for each patch in the original mailbox, with authorship and commit log message each taken from the message containing each patch.

Another way to submit changes to a project is to tell the maintainer of that project to pull the changes from your repository using git-pull[1]. In the section "Getting updates with git pull" we described this as a way to get updates from the "main" repository, but it works just as well in the other direction.

If you and the maintainer both have accounts on the same machine, then you can just pull changes from each other's repositories directly; commands that accepts repository URLs as arguments will also accept a local directory name:

However, the more common way to do this is to maintain a separate public repository (usually on a different host) for others to pull changes from. This is usually more convenient, and allows you to cleanly separate private work in progress from publicly visible work.

You will continue to do your day-to-day work in your personal repository, but periodically "push" changes from your personal repository into your public repository, allowing other developers to pull from that repository. So the flow of changes, in a situation where there is one other developer with a public repository, looks like this:

                      you push
your personal repo ------------------> your public repo
      ^                                     |
      |                                     |
      | you pull                            | they pull
      |                                     |
      |                                     |
      |               they push             V
their public repo <------------------- their repo

Suppose you are a contributor to a large project, and you want to add a complicated feature, and to present it to the other developers in a way that makes it easy for them to read your changes, verify that they are correct, and understand why you made each change.

If you present all of your changes as a single patch (or commit), they may find that it is too much to digest all at once.

If you present them with the entire history of your work, complete with mistakes, corrections, and dead ends, they may be overwhelmed.

So the ideal is usually to produce a series of patches such that:

We will introduce some tools that can help you do this, explain how to use them, and then explain some of the problems that can arise because you are rewriting history.

Suppose that you create a branch "mywork" on a remote-tracking branch "origin", and create some commits on top of it:

You have performed no merges into mywork, so it is just a simple linear sequence of patches on top of "origin":

 o--o--o <-- origin
        \
         o--o--o <-- mywork

Some more interesting work has been done in the upstream project, and "origin" has advanced:

 o--o--O--o--o--o <-- origin
        \
         a--b--c <-- mywork

At this point, you could use "pull" to merge your changes back in; the result would create a new merge commit, like this:

 o--o--O--o--o--o <-- origin
        \        \
         a--b--c--m <-- mywork

However, if you prefer to keep the history in mywork a simple series of commits without any merges, you may instead choose to use git-rebase(1):

This will remove each of your commits from mywork, temporarily saving them as patches (in a directory named ".dotest"), update mywork to point at the latest version of origin, then apply each of the saved patches to the new mywork. The result will look like:

 o--o--O--o--o--o <-- origin
                 \
                  a'--b'--c' <-- mywork

In the process, it may discover conflicts. In that case it will stop and allow you to fix the conflicts; after fixing conflicts, use "git add" to update the index with those contents, and then, instead of running git-commit, just run

and git will continue applying the rest of the patches.

At any point you may use the —abort option to abort this process and return mywork to the state it had before you started the rebase:

We saw in the section called “Fixing a mistake by editing history” that you can replace the most recent commit using

which will replace the old commit by a new commit incorporating your changes, giving you a chance to edit the old commit message first.

You can also use a combination of this and git-rebase(1) to edit commits further back in your history. First, tag the problematic commit with

(Either gitk or git-log may be useful for finding the commit.)

Then check out that commit, edit it, and rebase the rest of the series on top of it (note that we could check out the commit on a temporary branch, but instead we're using a detached head):

When you're done, you'll be left with mywork checked out, with the top patches on mywork reapplied on top of your modified commit. You can then clean up with

Note that the immutable nature of git history means that you haven't really "modified" existing commits; instead, you have replaced the old commits with new commits having new object names.

Given one existing commit, the git-cherry-pick(1) command allows you to apply the change introduced by that commit and create a new commit that records it. So, for example, if "mywork" points to a series of patches on top of "origin", you might do something like:

And browse through the list of patches in the mywork branch using gitk, applying them (possibly in a different order) to mywork-new using cherry-pick, and possibly modifying them as you go using commit —amend.

Another technique is to use git-format-patch to create a series of patches, then reset the state to before the patches:

Then modify, reorder, or eliminate patches as preferred before applying them again with git-am(1).

There are numerous other tools, such as stgit, which exist for the purpose of maintaining a patch series. These are outside of the scope of this manual.

The primary problem with rewriting the history of a branch has to do with merging. Suppose somebody fetches your branch and merges it into their branch, with a result something like this:

 o--o--O--o--o--o <-- origin
        \        \
         t--t--t--m <-- their branch:

Then suppose you modify the last three commits:

         o--o--o <-- new head of origin
        /
 o--o--O--o--o--o <-- old head of origin

If we examined all this history together in one repository, it will look like:

         o--o--o <-- new head of origin
        /
 o--o--O--o--o--o <-- old head of origin
        \        \
         t--t--t--m <-- their branch:

Git has no way of knowing that the new head is an updated version of the old head; it treats this situation exactly the same as it would if two developers had independently done the work on the old and new heads in parallel. At this point, if someone attempts to merge the new head in to their branch, git will attempt to merge together the two (old and new) lines of development, instead of trying to replace the old by the new. The results are likely to be unexpected.

You may still choose to publish branches whose history is rewritten, and it may be useful for others to be able to fetch those branches in order to examine or test them, but they should not attempt to pull such branches into their own work.

For true distributed development that supports proper merging, published branches should never be rewritten.

Instead of using git-remote(1), you can also choose just to update one branch at a time, and to store it locally under an arbitrary name:

The first argument, "origin", just tells git to fetch from the repository you originally cloned from. The second argument tells git to fetch the branch named "todo" from the remote repository, and to store it locally under the name refs/heads/my-todo-work.

You can also fetch branches from other repositories; so

will create a new branch named "example-master" and store in it the branch named "master" from the repository at the given URL. If you already have a branch named example-master, it will attempt to fast-forward to the commit given by example.com's master branch. In more detail:

In the previous example, when updating an existing branch, "git fetch" checks to make sure that the most recent commit on the remote branch is a descendant of the most recent commit on your copy of the branch before updating your copy of the branch to point at the new commit. Git calls this process a fast forward.

A fast forward looks something like this:

 o--o--o--o <-- old head of the branch
           \
            o--o--o <-- new head of the branch

In some cases it is possible that the new head will not actually be a descendant of the old head. For example, the developer may have realized she made a serious mistake, and decided to backtrack, resulting in a situation like:

 o--o--o--o--a--b <-- old head of the branch
           \
            o--o--o <-- new head of the branch

In this case, "git fetch" will fail, and print out a warning.

In that case, you can still force git to update to the new head, as described in the following section. However, note that in the situation above this may mean losing the commits labeled "a" and "b", unless you've already created a reference of your own pointing to them.

If git fetch fails because the new head of a branch is not a descendant of the old head, you may force the update with:

Note the addition of the "+" sign. Alternatively, you can use the "-f" flag to force updates of all the fetched branches, as in:

Be aware that commits that the old version of example/master pointed at may be lost, as we saw in the previous section.

We saw above that "origin" is just a shortcut to refer to the repository that you originally cloned from. This information is stored in git configuration variables, which you can see using git-config(1):

If there are other repositories that you also use frequently, you can create similar configuration options to save typing; for example, after

then the following two commands will do the same thing:

Even better, if you add one more option:

then the following commands will all do the same thing:

You can also add a "+" to force the update each time:

Don't do this unless you're sure you won't mind "git fetch" possibly throwing away commits on mybranch.

Also note that all of the above configuration can be performed by directly editing the file .git/config instead of using git-config(1).

See git-config(1) for more details on the configuration options mentioned above.

The object database is literally just a content-addressable collection of objects. All objects are named by their content, which is approximated by the SHA1 hash of the object itself. Objects may refer to other objects (by referencing their SHA1 hash), and so you can build up a hierarchy of objects.

All objects have a statically determined "type" which is determined at object creation time, and which identifies the format of the object (i.e. how it is used, and how it can refer to other objects). There are currently four different object types: "blob", "tree", "commit", and "tag".

A "blob" object cannot refer to any other object, and is, as the name implies, a pure storage object containing some user data. It is used to actually store the file data, i.e. a blob object is associated with some particular version of some file.

A "tree" object is an object that ties one or more "blob" objects into a directory structure. In addition, a tree object can refer to other tree objects, thus creating a directory hierarchy.

A "commit" object ties such directory hierarchies together into a directed acyclic graph of revisions - each "commit" is associated with exactly one tree (the directory hierarchy at the time of the commit). In addition, a "commit" refers to one or more "parent" commit objects that describe the history of how we arrived at that directory hierarchy.

As a special case, a commit object with no parents is called the "root" commit, and is the point of an initial project commit. Each project must have at least one root, and while you can tie several different root objects together into one project by creating a commit object which has two or more separate roots as its ultimate parents, that's probably just going to confuse people. So aim for the notion of "one root object per project", even if git itself does not enforce that.

A "tag" object symbolically identifies and can be used to sign other objects. It contains the identifier and type of another object, a symbolic name (of course!) and, optionally, a signature.

Regardless of object type, all objects share the following characteristics: they are all deflated with zlib, and have a header that not only specifies their type, but also provides size information about the