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. 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 in the examples above). After you cd into this directory, you will see that it contains a copy of the project files, called the working tree, together with a special top-level directory named .git, which contains all the information about the history of the project.

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 of the project’s contents. In Git each such version is called a commit.

Those snapshots aren’t necessarily all arranged in a single line from oldest to newest; instead, work may simultaneously proceed along parallel lines of development, called branches, which may merge and diverge.

A single Git repository can track development on multiple branches. It does this by keeping a list of heads which reference the latest commit 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-switch[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 "SHA-1 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 Git concepts 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.

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 switch command normally expects a branch head, but will also accept an arbitrary commit when invoked with --detach; for example, you can check out the commit referenced by a tag:

The HEAD then refers to the SHA-1 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, called remote-tracking branches, which you can view using the -r option to git-branch[1]:

In this example, "origin" is called a remote repository, or "remote" for short. The branches of this repository are called "remote branches" from our point of view. The remote-tracking branches listed above were created based on the remote branches at clone time and will be updated by git fetch (hence git pull) and git push. See Updating a repository with git fetch for details.

You might want to build on one of these remote-tracking branches on a branch of your own, just as you would for a tag:

You can also check out origin/todo directly to examine it or write a one-off patch. See detached head.

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.

(Newly created refs are actually stored in the .git/refs directory, under the path given by their name. However, for efficiency reasons they may also be packed together in a single file; see git-pack-refs[1]).

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 gitrevisions[7].

After you clone a repository and commit a few changes of your own, you may wish to check the original repository for updates.

The git-fetch command, with no arguments, will update all of the remote-tracking branches to the latest version found in the original 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 staging:

If you run git fetch <remote> later, the remote-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 in "(no branch)". HEAD is now detached from any branch and points directly to a commit (with commit id 65934) that is reachable from "master" 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.

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". Choose 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.

Instead of git bisect visualize and then git reset --hard fb47ddb2db, you might just want to tell Git that you want to skip the current commit:

In this case, though, Git may not eventually be able to tell the first bad one between some first skipped commits and a later bad commit.

There are also ways to automate the bisecting process if you have a test script that can tell a good from a bad commit. See git-bisect[1] for more information about this and other git bisect features.

We have seen several ways of naming commits already:

There are many more; see the "SPECIFYING REVISIONS" section of the gitrevisions[7] 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]:

That will produce the diff between the tips of the two branches. If you’d prefer to find the diff from their common ancestor to test, you can use three dots instead of two:

Sometimes what you want instead is a set of patches; for this you can use git-format-patch[1]:

will generate a file with a patch for each commit reachable from test but not from master.

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.

Before creating any commits, you should introduce yourself to Git. The easiest way to do so is to use git-config[1]:

Which will add the following to a file named .gitconfig in your home directory:

See the "CONFIGURATION FILE" section of git-config[1] for details on the configuration file. The file is plain text, so you can also edit it with your favorite editor.

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 contents of a new or modified file, use

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

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:

You can also use git-gui[1] to create commits, view changes in the index and the working tree files, and individually select diff hunks for inclusion in the index (by right-clicking on the diff hunk and choosing "Stage Hunk For 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. The text up to the first blank line in a commit message is treated as the commit title, and that title is used throughout Git. For example, git-format-patch[1] turns a commit into email, and it uses the title 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 . practically useless, and they keep showing up in the output of git status.

You can tell Git to ignore certain files by creating a file called .gitignore in the top level of your working directory, with contents such as:

See gitignore[5] for a detailed explanation of the syntax. You can also place .gitignore files in other directories in your working tree, and they will apply to those directories and their subdirectories. The .gitignore files can be added to your repository like any other files (just run git add .gitignore and git commit, as usual), which is convenient when the exclude patterns (such as patterns matching build output files) would also make sense for other users who clone your repository.

If you wish the exclude patterns to affect only certain repositories (instead of every repository for a given project), you may instead put them in a file in your repository named .git/info/exclude, or in any file specified by the core.excludesFile configuration variable. Some Git commands can also take exclude patterns directly on the command line. See gitignore[5] for the details.

You can rejoin two diverging branches of development using git-merge[1]:

merges the development in the branch branchname into the current branch.

A merge is made by combining the changes made in branchname and the changes made up to the latest commit in your current branch since their histories forked. The work tree is overwritten by the result of the merge when this combining is done cleanly, or overwritten by a half-merged results when this combining results in conflicts. Therefore, if you have uncommitted changes touching the same files as the ones impacted by the merge, Git will refuse to proceed. Most of the time, you will want to commit your changes before you can merge, and if you don’t, then git-stash[1] can take these changes away while you’re doing the merge, and reapply them afterwards.

If the changes are independent enough, Git will automatically complete the merge and commit the result (or reuse an existing commit in case of fast-forward, see below). On the other hand, 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 committed 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 an ancestor of the other—​so every commit present in the current branch is already contained in the other branch—​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 too much space on disk or in memory. Some Git commands may automatically run git-gc[1], so you don’t have to worry about running it manually. However, compressing a large repository may take a while, so you may want to call gc explicitly to avoid automatic compression kicking in when it is not convenient.

After you clone a repository and commit 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, if you have master checked out, then this branch has been configured by git clone to get changes from the HEAD branch of the origin repository. So often you can accomplish the above with just a simple

This command will fetch changes from the remote branches to your remote-tracking branches origin/*, and merge the default branch into the current branch.

More generally, a branch that is created from a remote-tracking branch will pull by default from that branch. See the descriptions of the branch.<name>.remote and branch.<name>.merge options in git-config[1], and the discussion of the --track option in git-checkout[1], to learn how to control these defaults.

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.

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.

git format-patch can include an initial "cover letter". You can insert commentary on individual patches after the three dash line which format-patch places after the commit message but before the patch itself. If you use git notes to track your cover letter material, git format-patch --notes will include the commit’s notes in a similar manner.

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 their requirements for submitting patches.

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 accept repository URLs as arguments will also accept a local directory name:

or an ssh URL:

For projects with few developers, or for synchronizing a few private repositories, this may be all you need.

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:

We explain how to do this in the following sections.

A shallow clone, with its truncated history, is useful when one is interested only in recent history of a project and getting full history from the upstream is expensive.

A shallow clone is created by specifying the git-clone[1] --depth switch. The depth can later be changed with the git-fetch[1] --depth switch, or full history restored with --unshallow.

Merging inside a shallow clone will work as long as a merge base is in the recent history. Otherwise, it will be like merging unrelated histories and may have to result in huge conflicts. This limitation may make such a repository unsuitable to be used in merge based workflows.

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:

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

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

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 .git/rebase-apply), 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:

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:

If you need to reorder or edit a number of commits in a branch, it may be easier to use git rebase -i, which allows you to reorder and squash commits, as well as marking them for individual editing during the rebase. See Using interactive rebases for details, and Reordering or selecting from a patch series for alternatives.

We saw in Fixing a mistake by rewriting 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. This is useful for fixing typos in your last commit, or for adjusting the patch contents of a poorly staged commit.

If you need to amend commits from deeper in your history, you can use interactive rebase’s edit instruction.

Sometimes you want to edit a commit deeper in your history. One approach is to use git format-patch to create a series of patches and then reset the state to before the patches:

Then modify, reorder, or eliminate patches as needed before applying them again with git-am[1]:

You can also edit a patch series with an interactive rebase. This is the same as reordering a patch series using format-patch, so use whichever interface you like best.

Rebase your current HEAD on the last commit you want to retain as-is. For example, if you want to reorder the last 5 commits, use:

This will open your editor with a list of steps to be taken to perform your rebase.

As explained in the comments, you can reorder commits, squash them together, edit commit messages, etc. by editing the list. Once you are satisfied, save the list and close your editor, and the rebase will begin.

The rebase will stop where pick has been replaced with edit or when a step in the list fails to mechanically resolve conflicts and needs your help. When you are done editing and/or resolving conflicts you can continue with git rebase --continue. If you decide that things are getting too hairy, you can always bail out with git rebase --abort. Even after the rebase is complete, you can still recover the original branch by using the reflog.

For a more detailed discussion of the procedure and additional tips, see the "INTERACTIVE MODE" section of git-rebase[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:

Then suppose you modify the last three commits:

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

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.

The git-bisect[1] command correctly handles history that includes merge commits. However, when the commit that it finds is a merge commit, the user may need to work harder than usual to figure out why that commit introduced a problem.

Imagine this history:

Suppose that on the upper line of development, the meaning of one of the functions that exists at Z is changed at commit X. The commits from Z leading to A change both the function’s implementation and all calling sites that exist at Z, as well as new calling sites they add, to be consistent. There is no bug at A.

Suppose that in the meantime on the lower line of development somebody adds a new calling site for that function at commit Y. The commits from Z leading to B all assume the old semantics of that function and the callers and the callee are consistent with each other. There is no bug at B, either.

Suppose further that the two development lines merge cleanly at C, so no conflict resolution is required.

Nevertheless, the code at C is broken, because the callers added on the lower line of development have not been converted to the new semantics introduced on the upper line of development. So if all you know is that D is bad, that Z is good, and that git-bisect[1] identifies C as the culprit, how will you figure out that the problem is due to this change in semantics?

When the result of a git bisect is a non-merge commit, you should normally be able to discover the problem by examining just that commit. Developers can make this easy by breaking their changes into small self-contained commits. That won’t help in the case above, however, because the problem isn’t obvious from examination of any single commit; instead, a global view of the development is required. To make matters worse, the change in semantics in the problematic function may be just one small part of the changes in the upper line of development.

On the other hand, if instead of merging at C you had rebased the history between Z to B on top of A, you would have gotten this linear history:

Bisecting between Z and D* would hit a single culprit commit Y*, and understanding why Y* was broken would probably be easier.

Partly for this reason, many experienced Git users, even when working on an otherwise merge-heavy project, keep the history linear by rebasing against the latest upstream version before publishing.

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:

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:

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,

adds the following to .git/config:

Also note that the above configuration can be performed by directly editing the file .git/config instead of using git-remote[1].

After configuring the remote, the following three commands will do the same thing:

See git-config[1] for more details on the configuration options mentioned above and git-fetch[1] for more details on the refspec syntax.

We already saw in Understanding History: Commits that all commits are stored under a 40-digit "object name". In fact, all the information needed to represent the history of a project is stored in objects with such names. In each case the name is calculated by taking the SHA-1 hash of the contents of the object. The SHA-1 hash is a cryptographic hash function. What that means to us is that it is impossible to find two different objects with the same name. This has a number of advantages; among others:

(See Object storage format for the details of the object formatting and SHA-1 calculation.)

There are four different types of objects: "blob", "tree", "commit", and "tag".

The object types in some more detail:

The index is a binary file (generally kept in .git/index) containing a sorted list of path names, each with permissions and the SHA-1 of a blob object; git-ls-files[1] can show you the contents of the index:

Note that in older documentation you may see the index called the "current directory cache" or just the "cache". It has three important properties:

The index is thus a sort of temporary staging area, which is filled with a tree which you are in the process of working on.

If you blow the index away entirely, you generally haven’t lost any information as long as you have the name of the tree that it described.

Always publish the submodule change before publishing the change to the superproject that references it. If you forget to publish the submodule change, others won’t be able to clone the repository:

In older Git versions it could be easily forgotten to commit new or modified files in a submodule, which silently leads to similar problems as not pushing the submodule changes. Starting with Git 1.7.0 both git status and git diff in the superproject show submodules as modified when they contain new or modified files to protect against accidentally committing such a state. git diff will also add a -dirty to the work tree side when generating patch output or used with the --submodule option:

You also should not rewind branches in a submodule beyond commits that were ever recorded in any superproject.

It’s not safe to run git submodule update if you’ve made and committed changes within a submodule without checking out a branch first. They will be silently overwritten:

If you have uncommitted changes in your submodule working tree, git submodule update will not overwrite them. Instead, you get the usual warning about not being able switch from a dirty branch.

The git-cat-file[1] command can show the contents of any object, though the higher-level git-show[1] is usually more useful.

The git-commit-tree[1] command allows constructing commits with arbitrary parents and trees.

A tree can be created with git-write-tree[1] and its data can be accessed by git-ls-tree[1]. Two trees can be compared with git-diff-tree[1].

A tag is created with git-mktag[1], and the signature can be verified by git-verify-tag[1], though it is normally simpler to use git-tag[1] for both.

High-level operations such as git-commit[1] and git-restore[1] work by moving data between the working tree, the index, and the object database. Git provides low-level operations which perform each of these steps individually.

Generally, all Git operations work on the index file. Some operations work purely on the index file (showing the current state of the index), but most operations move data between the index file and either the database or the working directory. Thus there are four main combinations:

You can examine the data represented in the object database and the index with various helper tools. For every object, you can use git-cat-file[1] to examine details about the object:

shows the type of the object, and once you have the type (which is usually implicit in where you find the object), you can use

to show its contents. NOTE! Trees have binary content, and as a result there is a special helper for showing that content, called git ls-tree, which turns the binary content into a more easily readable form.

It’s especially instructive to look at "commit" objects, since those tend to be small and fairly self-explanatory. In particular, if you follow the convention of having the top commit name in .git/HEAD, you can do

to see what the top commit was.

Git can help you perform a three-way merge, which can in turn be used for a many-way merge by repeating the merge procedure several times. The usual situation is that you only do one three-way merge (reconciling two lines of history) and commit the result, but if you like to, you can merge several branches in one go.

To perform a three-way merge, you start with the two commits you want to merge, find their closest common parent (a third commit), and compare the trees corresponding to these three commits.

To get the "base" for the merge, look up the common parent of two commits:

This prints the name of a commit they are both based on. You should now look up the tree objects of those commits, which you can easily do with

since the tree object information is always the first line in a commit object.

Once you know the three trees you are going to merge (the one "original" tree, aka the common tree, and the two "result" trees, aka the branches you want to merge), you do a "merge" read into the index. This will complain if it has to throw away your old index contents, so you should make sure that you’ve committed those—​in fact you would normally always do a merge against your last commit (which should thus match what you have in your current index anyway).

To do the merge, do

which will do all trivial merge operations for you directly in the index file, and you can just write the result out with git write-tree.

Sadly, many merges aren’t trivial. If there are files that have been added, moved or removed, or if both branches have modified the same file, you will be left with an index tree that contains "merge entries" in it. Such an index tree can NOT be written out to a tree object, and you will have to resolve any such merge clashes using other tools before you can write out the result.

You can examine such index state with git ls-files --unmerged command. An example:

Each line of the git ls-files --unmerged output begins with the blob mode bits, blob SHA-1, stage number, and the filename. The stage number is Git’s way to say which tree it came from: stage 1 corresponds to the $orig tree, stage 2 to the HEAD tree, and stage 3 to the $target tree.

Earlier we said that trivial merges are done inside git read-tree -m. For example, if the file did not change from $orig to HEAD or $target, or if the file changed from $orig to HEAD and $orig to $target the same way, obviously the final outcome is what is in HEAD. What the above example shows is that file hello.c was changed from $orig to HEAD and $orig to $target in a different way. You could resolve this by running your favorite 3-way merge program, e.g. diff3, merge, or Git’s own merge-file, on the blob objects from these three stages yourself, like this:

This would leave the merge result in hello.c~2 file, along with conflict markers if there are conflicts. After verifying the merge result makes sense, you can tell Git what the final merge result for this file is by:

When a path is in the "unmerged" state, running git update-index for that path tells Git to mark the path resolved.

The above is the description of a Git merge at the lowest level, to help you understand what conceptually happens under the hood. In practice, nobody, not even Git itself, runs git cat-file three times for this. There is a git merge-index program that extracts the stages to temporary files and calls a "merge" script on it:

and that is what higher level git merge -s resolve is implemented with.

All objects have a statically determined "type" 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".

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 data in the object. It’s worth noting that the SHA-1 hash that is used to name the object is the hash of the original data plus this header, so sha1sum file does not match the object name for file.

As a result, the general consistency of an object can always be tested independently of the contents or the type of the object: all objects can be validated by verifying that (a) their hashes match the content of the file and (b) the object successfully inflates to a stream of bytes that forms a sequence of <ascii type without space> + <space> + <ascii decimal size> + <byte\0> + <binary object data>.

The structured objects can further have their structure and connectivity to other objects verified. This is generally done with the git fsck program, which generates a full dependency graph of all objects, and verifies their internal consistency (in addition to just verifying their superficial consistency through the hash).

It is not always easy for new developers to find their way through Git’s source code. This section gives you a little guidance to show where to start.

A good place to start is with the contents of the initial commit, with:

The initial revision lays the foundation for almost everything Git has today, but is small enough to read in one sitting.

Note that terminology has changed since that revision. For example, the README in that revision uses the word "changeset" to describe what we now call a commit.

Also, we do not call it "cache" any more, but rather "index"; however, the file is still called cache.h. Remark: Not much reason to change it now, especially since there is no good single name for it anyway, because it is basically the header file which is included by all of Git’s C sources.

If you grasp the ideas in that initial commit, you should check out a more recent version and skim cache.h, object.h and commit.h.

In the early days, Git (in the tradition of UNIX) was a bunch of programs which were extremely simple, and which you used in scripts, piping the output of one into another. This turned out to be good for initial development, since it was easier to test new things. However, recently many of these parts have become builtins, and some of the core has been "libified", i.e. put into libgit.a for performance, portability reasons, and to avoid code duplication.

By now, you know what the index is (and find the corresponding data structures in cache.h), and that there are just a couple of object types (blobs, trees, commits and tags) which inherit their common structure from struct object, which is their first member (and thus, you can cast e.g. (struct object *)commit to achieve the same as &commit->object, i.e. get at the object name and flags).

Now is a good point to take a break to let this information sink in.

Next step: get familiar with the object naming. Read Naming commits. There are quite a few ways to name an object (and not only revisions!). All of these are handled in sha1_name.c. Just have a quick look at the function get_sha1(). A lot of the special handling is done by functions like get_sha1_basic() or the likes.

This is just to get you into the groove for the most libified part of Git: the revision walker.

Basically, the initial version of git log was a shell script:

What does this mean?

git rev-list is the original version of the revision walker, which always printed a list of revisions to stdout. It is still functional, and needs to, since most new Git commands start out as scripts using git rev-list.

git rev-parse is not as important any more; it was only used to filter out options that were relevant for the different plumbing commands that were called by the script.

Most of what git rev-list did is contained in revision.c and revision.h. It wraps the options in a struct named rev_info, which controls how and what revisions are walked, and more.

The original job of git rev-parse is now taken by the function setup_revisions(), which parses the revisions and the common command-line options for the revision walker. This information is stored in the struct rev_info for later consumption. You can do your own command-line option parsing after calling setup_revisions(). After that, you have to call prepare_revision_walk() for initialization, and then you can get the commits one by one with the function get_revision().

If you are interested in more details of the revision walking process, just have a look at the first implementation of cmd_log(); call git show v1.3.0~155^2~4 and scroll down to that function (note that you no longer need to call setup_pager() directly).

Nowadays, git log is a builtin, which means that it is contained in the command git. The source side of a builtin is

Sometimes, more than one builtin is contained in one source file. For example, cmd_whatchanged() and cmd_log() both reside in builtin/log.c, since they share quite a bit of code. In that case, the commands which are not named like the .c file in which they live have to be listed in BUILT_INS in the Makefile.

git log looks more complicated in C than it does in the original script, but that allows for a much greater flexibility and performance.

Here again it is a good point to take a pause.

Lesson three is: study the code. Really, it is the best way to learn about the organization of Git (after you know the basic concepts).

So, think about something which you are interested in, say, "how can I access a blob just knowing the object name of it?". The first step is to find a Git command with which you can do it. In this example, it is either git show or git cat-file.

For the sake of clarity, let’s stay with git cat-file, because it

So, look into builtin/cat-file.c, search for cmd_cat_file() and look what it does.

Let’s skip over the obvious details; the only really interesting part here is the call to get_sha1(). It tries to interpret argv[2] as an object name, and if it refers to an object which is present in the current repository, it writes the resulting SHA-1 into the variable sha1.

Two things are interesting here:

You will see both of these things throughout the code.

Now, for the meat:

This is how you read a blob (actually, not only a blob, but any type of object). To know how the function read_object_with_reference() actually works, find the source code for it (something like git grep read_object_with | grep ":[a-z]" in the Git repository), and read the source.

To find out how the result can be used, just read on in cmd_cat_file():

Sometimes, you do not know where to look for a feature. In many such cases, it helps to search through the output of git log, and then git show the corresponding commit.

Example: If you know that there was some test case for git bundle, but do not remember where it was (yes, you could git grep bundle t/, but that does not illustrate the point!):

In the pager (less), just search for "bundle", go a few lines back, and see that it is in commit 18449ab0. Now just copy this object name, and paste it into the command line

Voila.

Another example: Find out what to do in order to make some script a builtin:

You see, Git is actually the best tool to find out about the source of Git itself!

From a tarball:

From a remote repository:

Instead of basing a new branch on current HEAD (the default), use:

Create and switch to a new branch at the same time:

Update and examine branches from the repository you cloned from:

Fetch a branch from a different repository, and give it a new name in your repository:

Keep a list of repositories you work with regularly:

Search for regressions:

Make sure Git knows who to blame:

Select file contents to include in the next commit, then make the commit:

Or, prepare and create the commit in one step:

Importing or exporting patches:

Fetch a branch in a different Git repository, then merge into the current branch:

Store the fetched branch into a local branch before merging into the current branch:

After creating commits on a local branch, update the remote branch with your commits:

When remote and local branch are both named "test":

Shortcut version for a frequently used remote repository:

Check for corruption:

Recompress, remove unused cruft:

This is a work in progress.

The basic requirements:

Think about how to create a clear chapter dependency graph that will allow people to get to important topics without necessarily reading everything in between.

Scan Documentation/ for other stuff left out; in particular:

Scan email archives for other stuff left out

Scan man pages to see if any assume more background than this manual provides.

Add more good examples. Entire sections of just cookbook examples might be a good idea; maybe make an "advanced examples" section a standard end-of-chapter section?

Include cross-references to the glossary, where appropriate.

Add a section on working with other version control systems, including CVS, Subversion, and just imports of series of release tarballs.

Write a chapter on using plumbing and writing scripts.

Alternates, clone -reference, etc.

More on recovery from repository corruption. See: https://lore.kernel.org/git/Pine.LNX.4.64.0702272039540.12485@woody.linux-foundation.org/ https://lore.kernel.org/git/Pine.LNX.4.64.0702141033400.3604@woody.linux-foundation.org/