How can you use git bisect to determine the source of a (regression) bug?

Suppose you are trying to find the commit that broke a feature that was known to work in previous versions. You start a bisect session as follows:

• First, commit or stash you unfinished work.
• Initialize the bisect with:

git bisect start

• Next, mark your commits with good or bad labels by either specifying the commit SHA or checking out to the commit.

git checkout 1234567
git bisect good

OR

git bisect good 1234567

• Then it will respond with

Bisecting: 337 revisions left to test after this (roughly 9 steps)

• Keep repeating the process: compile the tree, test it, and depending on whether it is good or bad run git bisect good or git bisect bad to ask for the next commit that needs testing.
• Eventually there will be no more revisions left to inspect, and the command will print out a description of the first bad commit. The reference refs/bisect/bad will be left pointing at that commit.
• After a bisect session, to clean up the bisection state and return to the original HEAD, issue the following command:

git bisect reset