gergelypolonkai-web-jekyll/_posts/2015-02-26-using-git-bisect-to-find-the-first-good-commit.markdown

47 lines
2.2 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
layout: post
title: "Using Git bisect to find the first good commit"
date: 2015-02-26 10:42:56
tags: [git]
permalink: /blog/2015/2/26/using-git-bisect-to-find-the-first-good-commit
published: true
author:
name: Gergely Polonkai
email: gergely@polonkai.eu
---
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 customers 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 dont 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 customers 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 dont 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:
{% gist a98f4aab84659d60364e %}