$ git bisect start
    $ git bisect good <sha>
    $ git bisect bad master
    git will do all the hard work for you. You just have to run your tests at each point that git prompts you, and tell it whether it passed or not:
    $ git bisect bad (or good)

Props to the author for describing 'git bisect', which is a big time saver; but I'm always surprised that articles like this don't go on to mention the even more amazing 'git bisect run', which automates the "run your tests at each point and tell it whether it passed" part:

    $ git bisect start
    $ git bisect good <sha>
    $ git bisect bad master
    $ git bisect run rspec spec/path/to/failing_spec.rb
    ... wait a bit ...
    5243cafebabe is the last bad commit

You can give it any shell command, and it'll automatically bisect, run the command, mark the current commit as good or bad depending on the shell return code of the command, then bisect again, etc.

It's right there in the man page, but for some reason seems to be little known (or at least talked about).

I suppose automating this is not too difficult. Something like:

    $ git bisect start --good <sha> --run rspec spec/path/to/failing_spec.rb
    ... wait longer ...
    5243cafebabe is the last bad commit

I love git grep:

    $ git grep foo

It's often faster than running regular grep and does nice things like not inspecting ignored files.

I also find myself using git shortlog when preparing releases. e.g.:

    $ git shortlog v1.6.2..

...and it shows me a nice summary of changes since the "v1.6.2" tag.

"git diff --color-words" and "git difftool" are pretty awesome too.

I wouldn't consider these advanced but they are lesser-known.

Latest awesome git feature I found: http://www.kernel.org/pub/software/scm/git/docs/git-notes.ht...

I'm using git notes to annotate my commits with metadata about what bugs they fix, how stable they've proven to be in practice, and the dependencies between commits: https://rwmj.wordpress.com/2011/03/28/half-baked-ideas-class...

Last time I looked into 'git notes' it wouldn't preserve the notes attached to a commit when you amend / rebase / cherry-pick the commit. It seems that git now supports this! From the git-notes manpage:

  notes.rewrite.<command>
    When rewriting commits with <command> (currently amend or rebase),
    if this variable is false, git will not copy notes from the original
    to the rewritten commit. Defaults to true.

The "Filter-Branch" tip was the most helpful tip for me, since I've been there and deleted my whole repo as quickly as possible not knowing other solutions existed.

http://help.github.com/removing-sensitive-data/