You must have encountered, a long time has not modified the function, inexplicable problems? Naked eye code, repeated logic can not find the problem point? The function was fine two days ago, how can this not today? I have changed so many codes in these two days. Is it the Bug caused by that one change?

Sometimes it is not easy to troubleshoot such non-crash bugs. Git Bisect is what you need!

Basic use of Git Bisect

Git Bisect is a dichotomy debugging tool provided by Git. It can perform dichotomy segmentation according to our selected commit, and quickly locate the wrong commit. To help us narrow down the code with minimal changes so we can quickly locate problems.

Git Bisect is simple, based on a few basic commands:

  • Git bisect start: Prepare bisect debug.
  • Git bisect good: Marks a commit as “good”.
  • Git bisect bad: Marks a commit as “bad”.
  • Git bisect reset: Exits bisect debug.

Git bisect: git bisect: git Bisect: Git Bisect: Git Bisect: Git Bisect: Git Bisect: Git Bisect

Git Bisect workflow

I made 6 commits myself and used git log to see my commit record.

Let’s assume that during my normal development phase, when V6 is committed, I suddenly find a Bug. I can’t locate the problem, but I can clearly know that there is no such Bug during V1 commit phase.

In this case, v6 is a bad release and V1 is a good release, and git bisect can be used to find out which commit the problem is coming from.

Remember that order?

We start bisect debug with git bisect start, then use Git bisect good and Git bisect Bad to mark the correct and wrong commit, respectively.

For each commit, there is a sha-1 value that is unique to that commit. Since it is too long to enter or read, you can use the first bits as shorthand.

Git Bisect can help us locate intermediate commit V3 immediately after the correct and wrong commit is marked.

Now that the HEAD is pointing to the v3 submitted code, you can use git status to check the current status.

So we can run the project directly, based on the V3 version of the code, and test to see if there is a problem with the commit.

After testing, we found that the v3 submission code version did not reproduce the Bug, so we were able to narrow the scope of the error submission to between V4, V5 and V6.

At this point, we just need to use Git good to flag that the V3 version is correct.

Once V3 is marked as good, another binary is made, this time for an intermediate commit V5.

After testing the v5 submitted version code, it was found to be defective. Let’s go ahead and mark it with Git bisect Bad.

When V5 has a problem, there is now only one v4 release in the middle, so the commit is immediately directed to V4.

We continued to test the v4 version of the code, found problems with v4 as well, and continued to mark it as bad.

At this point, it’s clear that the bad commit is V4, and Git directly identifies the bad commit for us.

Although it is identified here that the bad commit is a V4 problem, we just need to read the V4 commit code carefully, and then locate the problem code, and we are there. Instead of fixing bugs on the V4 commit, we should exit bisect debug and make changes on the latest commit. Here, use git bisect reset to exit and make changes.

That’s git Bisect’s complete workflow.

Third, Bisect regret medicine

Marking submissions with good and bad is manual, and errors are inevitable. When submitting less, the worst thing you can do is reset and start all over again.

But if there are dozens of submissions, going through Bisect all over again can be tricky. With this in mind, Git has prepared a medicine for us to regret.

Erasing the previous mark state involves a command:

  • Git bisect replay: Resets to a state.

Git bisect log > log. TXT output log file. We need to modify the log file to determine the rollback point.

For example, we use the log command to output a log.txt file.

As you can see, this log.txt file is a record of everything we just did.

In this example, if the bad mark for V5 is wrong, delete all the logs under this operation and execute git bisect replay log.txt.

This will fall back to where the V5 commit is judged and re-marked.

When modifying the log.txt file, it is best to delete the file and not change the order. After all, we only want a rollback action, not to change any of our previous actions.

Today in the background of chengxiang Ink shadow public account, reply “growth”. I will send you some of my collation of learning materials, including: Android decompile, algorithm, design pattern, virtual machine, Linux, Kotlin, Python, crawler, Web project source.

Recommended reading:

  • Drawable these common tips, improve development efficiency!
  • Android soft keyboard show and hide, so the operation is right
  • Android decompiler, jADX advanced skills
  • 6 simple tips on how to write Clean Code
  • Write your first Dalvik version of HelloWorld by hand!