How to use git bisect to find errors

How do I debug almost all issues involving long-term change history, use Git to track, and find the time when errors are introduced in the code

Sometimes we work on projects for a long, long time. We may make a perfect 1.0 version, then release it to the public, then start bug fixes, then receive feature requests and work on improving the application.

At some point in the process, you will getRegression error: Unexpected problems caused by irrelevant changes to the code.

Although you haven't really changed that part of the code recently, some things haven't worked as expected.

Or maybe you touched the file or function so many times that you forgot what changes might have caused the problem reported to you.

Anyway, the first thing isDetermine where the error is.

If you are using a version control system, for exampleGit, Things are easier. You can go back in time and find out the exact commit that introduced the change. This is important when working in a team, because other people may already be doing this work, and if they caused an error, you may not know what to do-apart from asking them to fix it, because Git will do it for you Provide this information.

One way is to manually check out certain specific submissions. For example, you can start by checking whether yesterday's code base version is normal.

I useGitHub desktop, Awesome Git clientGitHub. It is very suitable for daily use, but does not allow me to check a submission. Some other clients are fine, but you can useCommand Line.


git checkout <COMMIT_SHA>

where is itIs the commit you want to roll back. It looks like5a06d3ca5e7adb6e67.

If the problem persists, try to perform the same operation on another commit from the previous day, and so on, until you find a commit whose code works.

Now you need to applyDivide and conquerPrinciple, and then choose a submission between the last one you tried (invalid) and the feasible one.

Repeat the process, halving the interval between each submission until you determine which submission is causing the problem.

This is a common and useful thing, so Git introducedbisectCommand to automate this process.

Start with your latest submission. usegit checkout your-branch-name, E.ggit checkout masterIf you have already checked out an earlier submission.

Then run:

git bisect start

Nothing happened you need to tell Git onebadSubmit a reference, where the code does not work:

git bisect bad HEAD

with oneOkSubmit, where does the code work:

git bisect good 7f4d976e7540e28c6b0

Git starts the process:

Bisecting: 3 revisions left to test after this (roughly 2 steps)
[d18ebf1c7db9a9b44e8facc5ddb3551e641a64e2] fixes #25

Look, you have 6 commits between HEAD and the great commit I mentioned. Git tells me that there are two more steps until the problematic commit is found.

I go to test the code, and then tell Git the result:git bisect badorgit bisect goodDepends on success.

Repeat until you find the wrong commit, then rungit bisect resetGo back to HEAD to commit.

Git will guide you through the halving operation. You enter the submitted SHA

More git tutorials: