TL;DR
git bisect start <bad_commit> <good_commit>
Git bisect can save you a lot of time if you have to track the exact commit that introduced that bug (you may also find out that you introduced that yourself).
Let’s say you have a repo in a good state.
As time goes on, other developers commit their code, make changes, and everything look right because conflicts are resolved, tests pass, builds build.
So far so good.
And then QA hits: that thing you knew was working 100% it isn’t anymore.
You get a glass of liquor, sit by the fireplace and comand your butler “Release the hounds“. And start the git blame.
But scanning through a week worth of work, if the repo is large and the developers are quite a few, can take quite some time to find the culprit, expecially if you have to run some tests to check wether the commit is good or not.
Here git bisect comes handy.
With git bisect you just have to identify one bad commit and a good commit, then it will get the range between them and checkout in the middle (hence bisect).
You test the checkout and tell git if it is good or bad, and it will repeat the process so the range becomes shorter and shorter, untill a single commit is left.
That’s where the bug was introduced.
Let’s see an example:
The current commit is known to be bad
The know good commit is aa238a0
> git bisect start // start the bisect
> git bisect bad // mark the current commit at bad
> git checkout aa238a0 // go to the good commit
> git bisect good // mark the current commit good
Git will checkout a commit in the middle so you can review it.
> git bisect good
Bisecting: 5 revisions left to test after this (roughly 3 steps)
[f9c99aef47dd865a4bd15545a18de7b03f09d780] hey oh
Review the files, they are still bad, mark the commit again.
> git bisect bad
Bisecting: 2 revisions left to test after this (roughly 2 steps)
[6055332a77d6925b9225159a80623cf6d10be97b] another test
This one is good, mark it.
> git bisect good
Bisecting: 0 revisions left to test after this (roughly 1 step)
[826696448e48ad9ed52239a3e746616e6eeb1989] teipo
Bad again, mark it.
> git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[74ab31899d3ddf3aa5d70e4bb318280eb89fe1c3] typo
Good, mark it.
> git bisect good
826696448e48ad9ed52239a3e746616e6eeb1989 is the first bad commit
commit 826696448e48ad9ed52239a3e746616e6eeb1989
Author: it_was_indeed_yourself
Date: Mon Jun 5 23:39:26 2017 +0200teipo
:000000 100644 0000000000000000000000000000000000000000 2011421b6a38b0fd51a2e600de4ef5fe6e26496f A bad-file.png
:100644 100644 21941c42e8565b36db082cdeca95e3072392b748 6b51d1612fab6f3137d41f760d0edd1524543068 M oh.txt
Here we go! we found the first bad commit!
This is obviously a very simple example.
For more complex codebases git even supports scripts to be run automatically to decide whether a commit is good or bad.
See more about this time-saving tool in the official documentation.
Gnafu Braindumps 