Fehlersuche mit Git Bisect

Imagine a bug appears in your project, but you're not sure which recent change caused it. Manually checking each commit can be a huge time sink!

git bisect is a powerful Git command that uses a binary search algorithm to quickly find the exact commit that introduced a bug.

How does git bisect work so fast? It's like a game of 'hot or cold' with your commit history.

• You tell Git a commit you know is bad (has the bug).
• You tell Git a commit you know is good (before the bug existed).
• Git picks a commit roughly in the middle and asks you to test it.
• Based on your feedback, it halves the search space, repeating until the culprit is found.

To begin, first you need to tell Git you're starting a bisect session. Then, you mark the known 'bad' (buggy) commit and a known 'good' (working) commit.

You can use commit hashes, branch names, or tags.

After you define your good and bad commits, Git will automatically check out a commit in the middle of that range. Your job is to test the code at this commit.

• If the bug is present, mark it as bad.
• If the bug is NOT present, mark it as good.

Git will then move to the next commit, halving the remaining search space.

Once you've tested the currently checked-out commit, use these commands to tell Git whether it's good or bad:

• To mark the current commit as bad: git bisect bad
• To mark the current commit as good: git bisect good

Git will then automatically check out the next commit to test.

You'll repeat the 'test and mark' process. With each step, git bisect gets closer to the single commit that introduced the bug. It's much faster than checking commits one by one!

For a range of 100 commits, it takes at most 7 tests (log₂(100) ≈ 6.64).

Eventually, git bisect will narrow the range down to a single commit. It will then report the first 'bad' commit found, which is your bug introducer!

After finding the bug, it's crucial to exit the bisect session to return your repository to its original state (usually the branch you were on when you started).

Sometimes, git bisect might land on a commit that can't be tested (e.g., it doesn't compile, or dependencies are broken). In such cases, you can tell Git to skip it:

git bisect skip

Git will then pick another commit to test, making sure to exclude the skipped one from the potential range of the bug.

For even faster debugging, you can automate the testing process using git bisect run. This command takes a script that performs the test and exits with specific codes:

• 0: The commit is good.
• 1-127 (except 125): The commit is bad.
• 125: The commit should be skipped (e.g., cannot build).

Git will then run the script automatically for each commit until the bug is found.

Which of the following commands are essential when performing a manual git bisect to find a bug?

You've mastered git bisect! This powerful tool transforms bug hunting from a tedious chore into an efficient, systematic process using binary search.

• Start with git bisect start, defining good and bad commits.
• Test and mark commits as good or bad.
• Use git bisect skip for untestable commits.
• Automate with git bisect run for fast, hands-free debugging.
• Always finish with git bisect reset.

Happy bug hunting!