Debugging with Git Bisect

Git is a powerful version control system that helps developers manage and track changes in their codebase. However, as codebases grow, it can be challenging to identify the exact commit that introduced a bug. This is where the git bisect command comes in handy. In this post, we’ll dive into how git bisect works and how it can help you quickly identify the commit that caused a bug.

What is git bisect?

git bisect is a command that helps you find the commit that introduced a bug in your codebase. It works by dividing the history of your codebase into smaller and smaller parts and checking each part for the presence of the bug. When it finds the commit that introduced the bug, it stops the search and reports the result.

What is Binary Search

Binary search is an algorithm for finding an item in a sorted list of items. The algorithm works by dividing the list of items into two parts and then checking which part of the list contains the item being searched for.

The algorithm starts by checking the middle item of the list. If the item being searched for is less than the middle item, the algorithm continues the search in the left half of the list. If the item being searched for is greater than the middle item, the algorithm continues the search in the right half of the list.

The algorithm then repeats this process of dividing the list in half and checking the middle item until the item being searched for is found or it is determined that the item does not exist in the list.

Binary search is an efficient algorithm for searching large lists of items because it reduces the number of items that need to be checked by half with each iteration.

How git bisect Works

git bisect works by using a binary search algorithm to find the commit that introduced the bug. Here’s a high-level overview of how it works:

1. You start by running git bisect start. This tells Git that you want to start a bisect session.
2. Next, you run git bisect bad to mark the current commit as bad (i.e., the commit that has the bug).
3. Then, you run git bisect good <commit-hash> to mark a known good commit (i.e., a commit that doesn’t have the bug).
4. Git will then checkout a commit in the middle of the range between the bad and good commits.
5. You test the code to see if it has the bug.
6. If the code has the bug, you run git bisect bad. If it doesn’t, you run git bisect good.
7. Git will then checkout another commit in the middle of the remaining range and the process repeats until Git finds the commit that introduced the bug.

Using git bisect in Practice

Using git bisect in practice is relatively straightforward. Here’s a simple example to get you started:

$ git bisect start 
$ git bisect bad 
$ git bisect good <commit-hash>

Replace <commit-hash> with the hash of a known good commit. Git will then checkout a commit in the middle of the range and you can test the code to see if it has the bug. If it does, run git bisect bad. If it doesn’t, run git bisect good. Repeat this process until Git finds the commit that introduced the bug.

git bisect use cases

git bisect is a versatile tool that can be used in a variety of situations. Here are some common use cases for git bisect:

1. Finding the commit that introduced a bug: As mentioned in the previous answer, git bisect is particularly useful for identifying the commit that introduced a bug in your codebase. By dividing the history of your codebase into smaller and smaller parts, git bisect can help you quickly find the commit that caused the bug.
2. Debugging regressions: Regressions are bugs that were previously fixed but have reappeared. git bisect can be used to identify the commit that introduced the regression, allowing you to quickly fix the bug.
3. Testing patches: If you have a patch that you want to test, you can use git bisect to determine which commit the patch should be applied to. By marking the patch as good or bad, git bisect can help you find the right commit to apply the patch to.
4. Evaluating performance changes: git bisect can also be used to evaluate changes in performance over time. By marking a commit as good or bad based on its performance, git bisect can help you find the commit that caused a change in performance.
5. Comparing differences between branches: git bisect can be used to compare differences between two branches. By marking a commit as good or bad based on whether it’s present in one branch or the other, git bisect can help you find the commit that caused the difference between the branches.

git bisect walkthrough

Step 1: Start the Bisect Session

To start the git bisect session, run the following command in your terminal:

$ git bisect start

This command tells Git that you want to start a git bisect session.

Step 2: Mark the Current Commit as Bad

Next, you need to mark the current commit as bad. This means that the current commit has the bug that you’re trying to troubleshoot. To mark the current commit as bad, run the following command:

$ git bisect bad

Step 3: Mark a Known Good Commit

Next, you need to mark a known good commit as such. A known good commit is a commit that doesn’t have the bug you’re trying to troubleshoot. To mark a known good commit, run the following command, replacing <commit-hash> with the hash of the known good commit:

$ git bisect good <commit-hash>

Step 4: Checkout a Commit and Test the Code

At this point, git bisect will checkout a commit in the middle of the range between the bad and good commits. You can then test the web application code to see if it has the bug.

Step 5: Mark the Commit as Bad or Good

If the code has the bug, run the following command:

$ git bisect bad

If the code doesn’t have the bug, run the following command:

$ git bisect good

Step 6: Repeat the Process

Repeat steps 4 and 5 until git bisect finds the commit that introduced the bug. When git bisect finds the commit, it will stop the search and report the result.

Step 7: End the Bisect Session

When you’re done troubleshooting, you can end the git bisect session by running the following command:

$ git bisect reset

This command will checkout the original branch that you were on before you started the git bisect session.

git bisect commands and sub-commands

git bisect has several subcommands that can be used to control the bisect process:

1. git bisect start: This command starts the git bisect session.
2. git bisect bad: This command marks the current commit as bad, meaning that it has the bug that you’re trying to find.
3. git bisect good: This command marks the current commit as good, meaning that it doesn’t have the bug that you’re trying to find.
4. git bisect skip: This command allows you to skip a commit that you don’t want to test.
5. git bisect reset: This command ends the git bisect session and returns to the original branch.
6. git bisect visualize: This command opens a visual representation of the git bisect process, allowing you to see the steps taken during the bisect process.
7. git bisect replay: This command allows you to replay the git bisect process, starting from a specific commit.
8. git bisect log: This command displays a log of the git bisect session, including the results of each test.

These subcommands allow you to control and monitor the git bisect process, making it easier to find the commit that introduced a bug in your codebase.

Conclusion

git bisect is a powerful tool for finding the commit that introduced a bug in your codebase. It uses a binary search algorithm to divide the history of your codebase into smaller and smaller parts and check each part for the presence of the bug. With git bisect, you can quickly and easily identify the commit that caused a bug and get one step closer to fixing it.