Part of a good revision control system is the support it provides for “archaeology” and investigating a repository. Git provides several mechanisms to help you locate commits that meet certain criteria within your repository.
The git bisect command is a powerful tool for isolating a particular, faulty commit based on essentially arbitrary search criteria. git bisect is well suited to those times when you discover that something “wrong” or “bad” is affecting your repository and you know the code used to be fine. For example, let’s say you are working on the Linux kernel and a test boot fails, but you’re positive the boot worked sometime earlier—perhaps last week or at a previous release tag. In this case, your repository has transitioned from a known “good” state to a known “bad” state.
But when? Which commit caused it to break? That is precisely the question git bisect is designed to help you answer.
The only real search requirement is that, given a checked-out state of your repository, you are able to determine if it does or does not meet your search requirement. In this case, you have to be able to answer the question, “Does the version of the kernel checked out build and boot?” You also have to know a “good” and a “bad” version or commit before starting so that the search will be bounded.
git bisect is often used to isolate a particular commit that introduced some regression or bug into the repository. For example, if you were working on the Linux ...