This lesson's interactive features are locked, please to keep using them

How to Bisect

There are effectively 7 steps to bisecting:

Start the bisect with git bisect start
Select a "good" commit with git bisect good <commitish> (a commit where you're sure the bug wasn't present)
Select a bad commit via git bisect bad <commitish> (a commit where you're sure the bug was present)
Git will checkout a commit between the good and bad commits for you to test to see if the bug is present
Execute git bisect good or git bisect bad to say the current commit is good or bad
Loop back to step 4 (until git bisect completes)
Exit the bisect mode with git bisect reset

Assignment

Your boss just chewed you out because the scan.sh script should never have been added to the repo!

Not only does she want the contents of the script erased, but she wants to know when the script was added, and for you to fix it with a git revert so that the history of your royal screw-up is preserved.

Considering you can't remember when you wrote the script, you decide to use git bisect.

Start the bisect
You know the HEAD commit is bad, so mark it
You know the first commit (A) on main is good, so mark it
If the script's content is present (not just a TODO comment), mark the commit as bad, otherwise mark it as good
Repeat step 4 until git bisect completes, it should give you the hash of the commit that introduced the script
Use the git show HASH command to ensure that the commit introduced the script
Run git bisect reset to exit bisect mode
Revert the commit that introduced the script with a commit message starting with P:

Run and submit the CLI tests from the root of your repo.

If you're interested, the git blame command can be used to see who made the change, not just when it was made.