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
|