To make git ci into git commit it’s a simple git config --global alias.ci commit.

If you want to call external programs, use an exclamation mark (!). If you always find you’re running gitk --left-right HEAD...MERGE_HEAD to visually compare merge conflicts, execute git config --global alias.gitkconflict '!gitk --left-right HEAD...MERGE_HEAD'.

“What if I want to execute something that needs arguments?” you ask. If you just want the arguments appended to the end of the command, then you don’t have to do anything. The git ci example above works fine if you want to pass certain files to it. If you want more complicated arguments you can specify them with $<variable> notation.

A more complicated example that uses external commands and arguments comes from the git alias wiki page: git config alias.funcdiff '!sh -c "git show \"\$0:\$2\" | sed -n \"/^[^ \t].*\$3(/,/^}/p\" > .tmp1 && git show \"\$1:\$2\" | sed -n \"/^[^ \t].*\$3(/,/^}/p\" > .tmp2 && git diff .tmp1 .tmp2"'

When you call git funcdiff <old-rev> <new-rev> <path> <function> it will create two files (.tmp1 and .tmp2) that contain only <function> from <path> from the two different revisions and run git diff on them.

References:

• http://www.kernel.org/pub/software/scm/git/docs/git-config.html
• http://git.or.cz/gitwiki/Aliases

To tell git to use vimdiff as your mergetool run git config --global merge.tool vimdiff.

If I replay one of the git conflicting merges and run git mergetool, I see this:

(To recreate this yourself, in a clone of the git repository, execute git checkout -b test 7a937b2e7378699553b8f88d995f9e54e722a3c0 and git merge b468f0ce4881bf42ffc820b1cddad67dad17fd80)

In this case, the file as I knew it is on the left and the right section is the modifications made in the remote branch. You want to modify and save the center panel (ie. the one with the actual filename of the file with merge conflicts).

git mergetool is controlled by the command line, even if you’re using a graphical tool. What I mean is that it displays status and sometimes prompts you in the terminal that is was run in, even if you’re using a tool like meld or kdiff3.

If you run git mergetool without specify a file, it will pick the first one in the list and not let you move on till you’ve merged it completely. Be aware that it considers a file merged if it has been modified and the exit code of the merging program indicates that everything went well and marks the file as merged (I don’t currently know a way to unmark a merge conflicted file as merged).

Aside from these drawbacks, git mergetool makes it very simple to better visualize the differences in files when doing a manual merge.

git mergetool takes two optional arguments: -t and a list of filenames. -t lets you specify a mergetool without having to set any config options. If you pass a list of filenames to mergetool, it will only try to merge those files (assuming they’re marked as having merge confilicts).

References:

• http://www.kernel.org/pub/software/scm/git/docs/git-mergetool.html

To use the pickaxe, just pass the -S option. git log -Sgit-diff --pretty=oneline --abbrev-commit run on the git repository outputs this:

497c833... Documentation: convert "glossary" and "core-tutorial" to man pages
b27a23e... Documentation: convert tutorials to man pages
0e36f2d... git-p4: Removed git-p4 submit --direct.
2cd5dfd... Teach git-grep --name-only as synonym for -l
87f1b88... mailinfo: feed only one line to handle_filter() for QP input
fdcf39e... Include rev-list options in git-log manpage.
8b30aa5... git.el: Support for getting diffs from inside the log-edit buffer.
e25cfae... contrib: resurrect scripted git-revert.
530e741... Start preparing the API documents.
18ff365... git.el: Added a menu for git-status-mode.
cc2d6b8... don't mention index refreshing side effect in git-status docs
272bd3c... Include diff options in the git-log manpage
61fd255... gitweb: Update and improve gitweb/README file
79d3066... Consolidate command list to one.
8b014d7... git-svn: info --url [path]
e6fefa9... git-svn info: implement info command
5b98d9b... user-manual: mention "..." in "Generating diffs", etc.
c1a95fa... Documentation: customize diff-options depending on particular command
b43b0a3... git-p4: Add a helper function to parse the full git diff-tree output.
9e6c723... git-diff.txt: add section "output format" describing the diff formats
6b6012e... cvsexportcommit: fix for commits that do not have parents
0cec6db... gitweb: Fix and simplify "split patch" detection
0995520... Document additional 1.5.3.5 fixes in release notes

Because tig supports all the git options, running tig -Sgit-diff shows you the list of commits and lets you see the diffs by hitting enter.

The pickaxe can help find code that’s been deleted or moved, git blame won’t tell you about those lines at all. Any time you want to find out more about a piece of code than just who touched it last, the pickaxe is a good little tool to reach for.

References:

• http://www.kernel.org/pub/software/scm/git/docs/git-log.html
• http://www.kernel.org/pub/software/scm/git/docs/git-diff.html
• http://www.kernel.org/pub/software/scm/git/docs/git-format-patch.html

The identifier tells you that I was at the 178th commit after the v1.5.5.1 tag. Just in case history gets rewritten and the 178th commit changes or there are multiple 178th commits, we can use the hash g1f8115b to make sure it’s the right one.

Using git describe in this way you can create identifiers that work well in places where increasing version numbers are used (development snapshots, for example), but this wouldn’t be git-fu if there wasn’t more it could do.

If you use the –contains option, git describe can tell you where a commit is relative to a future tag. For example, the output of git describe --contains HEAD~90 is v1.5.5~7. It’s just as easy to refer to a revision after a tag as it is to refer to a revision before a tag.

You can also use things other than tags by using git describe --all which looks at any ref found in .git/refs/ (common directories in .git/refs/ are heads, remotes, and tags). These can be less helpful in the long run because heads and remotes often change. If you want to tell someone which commit you’re referring to without giving them an entire sha1, –all can be useful.

References:

• http://www.kernel.org/pub/software/scm/git/docs/git-describe.html

tig has a few command line options:

• tig show
• tig blame
• tig status

All of these options act the same as their git counterparts, except they show in its coloured pager.

When tig is running, you can get help by pressing ‘h’. tig’s views consist of main, diff, log, tree, blob, blame, pager, status, and stage. Most of these views are fairly simple and I’ll leave their use as an exercise for the reader.

Pressing ‘g’ in main view shows the revision graph:

This is what makes tig as useful as other visualization tools like qgit or gitk.

Pressing ‘enter’ on any of the commits in main view splits the window and shows the diff below. Vi’s ‘j’ and ‘k’ keys move the diff up and down.

tig blame can be more useful than a regular git blame because you can press ‘enter’ and view the diff that made the change to that line.

If tig doesn’t support some option that works with git, you can still use tig to page git’s output by piping git’s output into tig. It will still colour all the items it understands, detect commit hashes, and display diffs.

tig can be really helpful when doing development on a remote machine that doesn’t have vnc or any X tools installed.

References:

• http://jonas.nitro.dk/tig/

git cherry-pick has some useful options:

• -e|--edit
• -x
• -n|--no-commit
• -m <parent-number>

-e lets you edit the commit message before the patch is commited.

-x adds a note to the commit message explaining where it came from originally. This is helpful if you’re backporting a feature or fix from one branch to another.

-n applies the changes but doesn’t actually create a commit. This can be really helpful if you’re combining multiple commits from different places (it can be simpler than using git rebase).

-m <parent-number> lets you cherry pick from a merge. If you tell git cherry-pick which parent is the “mainline”, it can calculate the commit’s impact (its diff) relative to the mainline and apply that as a patch against your current branch.

References:

• http://www.kernel.org/pub/software/scm/git/docs/git-cherry-pick.html

     G   H   I   J
      \ /     \ /
       D   E   F
        \  |  / \
         \ | /   |
          \|/    |
           B     C
            \   /
             \ /
              A

(The most recent commit in this diagram is A. A is a merge commit between B and C.)

A repo with this sort of history is available here: http://xennet.org/git-rev-parse-example.tar.bz2

Everyone knows about the J^, F^1, and I~4 notation, but they’re less likely to know about the D..B, B…C, and ^J C notations. The former are different ways to refer to a single revision and the latter are ways to refer to ranges of revisions.

The r1..r2 and ^r2 r1 syntaxes are actually the same. They both mean all the commits reachable by r1 but not r2. The second syntax is slightly more powerful because you can say things like ^D ^F B. In our example above (D..B) those commits are E I J F B.

The r1…r2 syntax represents the symmetric difference. In other words, this is all the commits in r1 and r2 but not in both r1 and r2. This is all the commits that will be merged together if the two branches are merged. In our example above (B…C) those commits are G H D E B C.

If you were an integrator and wanted to review a contributor’s branch, and that contributor, during the course of development, merged from master a couple of times, how would you be able to find the commits that were only available in the contributor’s branch (contrib) and not in master? You could easily git log --no-merges ^master contrib (you need the –no-merges because the patches that merge master into contrib aren’t included in master). Using a GUI like tig (tig --no-merges ^master contrib), gitk, or qgit makes it trivially simple to inspect each of the diffs before integrating.

References:

• http://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html
• http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/git-rev-parse.txt;h=110e7ba71f48c54cb94f35e819583826e123a8b1;hb=HEAD . There’s a bug in the git man page and generated man page html. The illustration, by Jon Loeliger seems only to be correct in the original git-rev-parse.txt.

Let’s say we have history that looks something like this (from the official git repo):

8419d2e... git-format-patch --in-reply-to: accept  with angle brackets
767c98a... git-add -u: do not barf on type changes
f5de799... Remove duplicate note about removing commits with git-filter-branch
f28dd47... git-clone: improve error message if curl program is missing or not executable
568d2cd... git.el: Allow the add and remove commands to be applied to ignored files.
98acc3f... git.el: Allow selecting whether to display uptodate/unknown/ignored files.
1b65504... git.el: Keep the status buffer sorted by filename.
c32da69... hooks--update: Explicitly check for all zeros for a deleted ref.
80bffaf... git-commit: Allow partial commit of file removal.

All we know is that 8419d2e has the bug and 80bffaf works, so we run git bisect start 8419d2e 80bffaf. Git’s output looks like this:

$ git bisect start 8419d2e 80bffaf
Bisecting: 2 revisions left to test after this
[f28dd4774d4723e8251817e910dbdc5507282113] git-clone: improve error message if
curl program is missing or not executable

Now we’re right in the middle of these commits. We find that the bug existed at this point too, so we run git bisect bad:

$ git bisect bad
Bisecting: 0 revisions left to test after this
[c32da692de332d3c9a0b283066e3786af00f4931] hooks--update: Explicitly check for all
zeros for a deleted ref.

This commit doesn’t have the bug, so we run git bisect good:

$ git bisect good
f28dd4774d4723e8251817e910dbdc5507282113 is first bad commit
commit f28dd4774d4723e8251817e910dbdc5507282113
Author: Gerrit Pape
Date:   Thu Sep 13 11:36:22 2007 +0000

    git-clone: improve error message if curl program is missing or not executable

…snip…

    Signed-off-by: Gerrit Pape
    Signed-off-by: Junio C Hamano 

:100755 100755 18003ab4b39ad0a7848cc20db2f6ad55e1291264
5e582fe247892fa7dffc44556c939863c36edc35 M      git-clone.sh

Now we know the exact commit that caused the regression.

Sure, you could have done that with a temporary branch and git reset --hard, but things get a lot more complicated when merges are involved. git bisect doesn’t have problems walking down branches and keeping track of which sections are good and which sections are bad.

There are a few other options that git bisect has that can help a lot:

• git bisect visualize
• git bisect log
• git bisect replay
• git bisect run
• git bisect skip

git bisect visualize opens up the range you’re analyzing in gitk which lets you see which sections you’ve discounted as good or bad.

git bisect log shows you history that can be replayed by git bisect replay. Our example’s log looks like this:

# bad: [8419d2ee9ba8b375186a5c1019df8dfbce610aba] git-format-patch --in-reply-to:
accept  with angle brackets
# good: [80bffaf7fbe09ef62ecb9a6ffea70ac0171b456c] git-commit: Allow partial commit
of file removal.
git-bisect start '8419d2e' '80bffaf'
# bad: [f28dd4774d4723e8251817e910dbdc5507282113] git-clone: improve error
message if curl program is missing or not executable
git-bisect bad f28dd4774d4723e8251817e910dbdc5507282113
# good: [c32da692de332d3c9a0b283066e3786af00f4931] hooks--update: Explicitly
check for all zeros for a deleted ref.
git-bisect good c32da692de332d3c9a0b283066e3786af00f4931

If you screw up bisecting, you can use git bisect log, git bisect reset, and git bisect replay to go back and fix your mistakes.

If you can write a script to automatically test your regression, you can use git bisect run. Your script has to do its test and exit with a status code. If the status code is 0, the revision is good; if the status is between 1 and 127 (but not 125), the revision is bad; if the status is anything else (exit -1 is common), the automatic bisect process will stop; if the status is 125, it means skip that revision.

git bisect skip is used to tell git that you can’t test this revision. There can be cases where git won’t know which commit caused the problem if a skipped commit makes the bisect ambiguous.

Most newer version control systems (especially distributed ones) support bisect features. Subversion is the notable exception.

References:

• http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html

After you’ve done that, git rerere just basically works. Any time you have merge conflicts, it will automatically record the original and resolved states and replay them next time you try to merge. Any merge, rebase, or am action will use git rerere.

If you have a long-lived topic branch that you know will conflict when merged with another branch (say, master), you can do a git pull origin master, fix conflicts and commit, and then git reset --hard HEAD^. This way you can get the benefit of merging often without the history cluttering of many “useless merges”.

References:

• http://www.kernel.org/pub/software/scm/git/docs/git-rerere.html

Now, let’s go through these use cases one at a time, starting from the simplest.

If you’ve submitted patches to a maintainer, and all or some of them have been accepted to a project, your topic branch will no longer be the same as theirs (they could have applied them at a different point, added a signed-off tag, or many other things). To reconcile a topic branch with what’s in the current (remote) master branch, you could run git rebase origin/master from your topic branch. All the patches that match up exactly with patches in origin/master will disappear and all patches that were edited or not included will be created on top of origin/master. The topic branch you were in will then point to the newly created commits and the old commits will be relegated to the reflog.

If you realize that your topic branch actually has two totally separate topics in it, you can use the –onto option. A diagram helps to describe this better (diagram blatantly taken from git rebase man page):

                        H---I---J topicB
                       /
              E---F---G  topicA
             /
A---B---C---D  master

If you want to make topicA and topicB separate branches that both branch off of master, you would run git rebase --onto master topicA topicB. After running it, your repository would look like this:

             H'--I'--J'  topicB
            /
            | E---F---G  topicA
            |/
A---B---C---D  master

H’, I’, and J’ have the same contents as H, I, and J respectively but have different commit hashes because they have different parents.

If you want to change the order or contents of any commits in the past, git rebase -i is your friend. If you run something like git rebase -i HEAD~3 you will be dropped into an editor with lines something like this:

pick 428c9da Fix bugaboo
pick 503ffbe Some other patch
pick de6b9c5 Even another one

# Rebase fc08684..742098a onto fc08684
#
# Commands:
#  pick = use commit
#  edit = use commit, but stop for amending
#  squash = use commit, but meld into previous commit
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

By changing the first element of a line, you can choose to include the commit, stop rebasing when it gets to that commit (so you can change things), or combine two commits into one. You can also choose to throw away a commit (by deleting the line) and change the order of commits. This is the main way to modify git history in a more-than-just-the-most-recent-commit sense.

Remember that git rebase -i can also use the –onto option, so you could re-order, squash, and modify patches as you change their base from one point in history to another.

Because of how git rebase works, merges can be tricky. If you have to rebase over a merge (and don’t want the merge to just be included in one of the patches) be sure to use the -p (–preserve-merges) option with -i.

Also, because git rebase modifies history, it’s not a very nice command to run against commits that are publicly available. Other people don’t like it when they have commits that depend on your commits and you rewrite the history of your commits.