To begin bisecting, we simply type the following:

$ git bisect start

To mark the current commit (HEAD -> bug_hunting) as bad, we type the following:

$ git bisect bad

We also want to mark the last known good commit (master) as good:

$ git bisect good master
Bisecting: 11 revisions left to test after this (roughly 4 steps)
[9d2cd13d4574429dd0dcfeeb90c47a2d43a9b6ef] Build map part 11

This time, something happened. Git did a checkout of 9d2cd13, which it wants us to test and mark as either good or bad. It also tells us there are 11 revisions to test after this, and it can be done in approximately four steps. This is how the bisecting algorithm works: every time a commit is marked as good or bad, Git will checkout the one between the commit that has just been marked and the current commit of opposite value. In this way, Git quickly narrows down the number of commits to check. It also knows that there are approximately four steps, and this makes sense since, with 11 revisions left, the maximum number of tries is log₂(11) = 3.46 before the faulty commit is found.

We can test with the test.sh script we created previously, and based on the return value, mark the commit as good or bad:

$ ../test.sh; test $? -eq 0 && git bisect good || git bisect bad
# git bisect good
Bisecting: 5 revisions left to test after this (roughly 3 steps)
[c45cb51752a4fe41f52d40e0b2873350b95a9d7c] Build map part 16 

The test marks the commit as good and Git checks out the next commit to be marked, until we hit the commit that introduces the bug:

$ ../test.sh; test $? -eq 0 && git bisect good || git bisect bad 
# git bisect bad
Bisecting: 2 revisions left to test after this (roughly 2 steps)
[83c22a39955ec10ac1a2a5e7e69fe7ca354129af] Bugs...
$ ../test.sh; test $? -eq 0 && git bisect good || git bisect bad 
# git bisect bad
Bisecting: 0 revisions left to test after this (roughly 1 step)
[670ab8c42a6cb1c730c7c4aa0cc26e5cc31c9254] Build map part 13
$ ../test.sh; test $? -eq 0 && git bisect good || git bisect bad
# git bisect good
83c22a39955ec10ac1a2a5e7e69fe7ca354129afis the first bad commit
commit 83c22a39955ec10ac1a2a5e7e69fe7ca354129af
Author: HAL 9000 <[email protected]>
Date:   Tue May 13 09:53:45 2014 +0200
    
    Bugs...
    
:100644 100644 8a13f6bd858aefb70ea0a7d8f601701339c28bb0 1afeaaa370a2e4656551a6d44053ee0ce5c3a237 M map.txt

After four steps, Git has identified the 83c22a3 commit as the first bad commit. We can end the bisect session and take a closer look at the commit:

$ git bisect reset
Previous HEAD position was 670ab8c... Build map part 13
Switched to branch 'bug_hunting'
Your branch is up-to-date with 'origin/bug_hunting'.
$ git show 83c22a39955ec10ac1a2a5e7e69fe7ca354129af
commit 83c22a39955ec10ac1a2a5e7e69fe7ca354129af
Author: HAL 9000 <[email protected]>
Date:   Tue May 13 09:53:45 2014 +0200
    
  Bugs...
    
diff --git a/map.txt b/map.txt
index 8a13f6b..1afeaaa 100644
--- a/map.txt
+++ b/map.txt
@@ -34,6 +34,6 @@ Australia:
                    .-./     |.     :  :,
                   /           '-._/     _
                  /                '       
    -           .'                         *: Brisbane
    -        .-'                             ;
    -        |                               |
    +           .'        __/             *: Brisbane
    +        .-'          (oo)               ;
    +        |           //||              |
  

Clearly, a bug was introduced with this commit.

The following annotated screenshot shows the steps taken by the bisect session:

Note that the bisection algorithm actually hits the faulty commit in the third step, but it needs to look further to make sure that the commit isn't just a child commit of the faulty commit, and is in fact the commit that introduced the bug.