45 lines
2.4 KiB
ReStructuredText
45 lines
2.4 KiB
ReStructuredText
Using Git bisect to find the first good commit
|
||
##############################################
|
||
|
||
:date: 2015-02-26T10:42:56Z
|
||
:category: blog
|
||
:tags: git
|
||
:url: blog/2015/2/26/using-git-bisect-to-find-the-first-good-commit.html
|
||
:save_as: blog/2015/2/26/using-git-bisect-to-find-the-first-good-commit.html
|
||
:status: published
|
||
:author: Gergely Polonkai
|
||
|
||
Few months ago we “implemented” a bug in our software, which was released to the customers. We
|
||
continued development for two weeks when the first customer ticket arrived about the bug. We
|
||
successfully reproduced it with the customer’s version, but not with the development sources; it
|
||
turned out that one of the developers unconsciously fixed the bug. The devs spent some hours
|
||
finding where the fix lied before coming to me like “There is ``git-bisect`` which we can use to
|
||
find the commit where we messed up things. Is there a way to find where we fixed it?”
|
||
|
||
For those who don’t know this feature, you have to mark a known “good” and “bad” commit, then
|
||
git-bisect will go through the commits between this two, present you the corresponding snapshots,
|
||
and you have to mark each of them as “good” or “bad”. At the end, you will get a commit hash
|
||
where the bug first occured.
|
||
|
||
As it turned out, our developers’ problem rooted in the naming convention of git-bisect: they
|
||
assumed that the “good” commit must be a working one, while a “bad” one must be the buggy. In
|
||
this case, we did the following:
|
||
|
||
The commit with the customer’s release tag was marked as good (even though this had the bug), and
|
||
the latest commit on our development branch was marked as “bad” (even though the bug was fixed by
|
||
then). Now with every snapshot presented by git-bisect we had to do the opposite what you usually
|
||
do: mark commits still having the bug as “good”, and commits that don’t as “bad”. At the end, we
|
||
had the hash of the commit that fixed the bug (among some other things; luckily, the developer who
|
||
pushed that commit had a workflow that introduced a lot of cherry-picking and squashing before the
|
||
push, so he could easily find the bit that actually fixed the problem in his local repository with
|
||
the same technique).
|
||
|
||
`This StackOverflow answer <http://stackoverflow.com/a/17153598/1305139>`_ suggests the very same,
|
||
but with some aliases:
|
||
|
||
.. code-block:: dosini
|
||
|
||
[alias]
|
||
bisect-fixed = bisect bad
|
||
bisect-unfixed = bisect good
|