Huge, huge thanks to git bisect! With its help, I …

Huge, huge thanks to git bisect! With its help, I just sorted out a huge argument about who removed a piece of code and when.  With an actively developed project among few developers and branches, it’s not trivial to say when the change was introduced.  Unless, of course, you are using git bisect.  Every developer should know how to use it.

Think Like a Git

Being a sysadmin and web developer I read plenty of technical documentation – manuals, tutorials, howtos, and so on and so forth. Most of it is usually very dry and boring. Unless, of course, we are talking about Open Source Software. That area is often very human, with plenty of humor and an excellent examples.

Today I came across a very nice website which explains how Git – the de facto version control system in Open Source community – works. The site is called Think Like a Git. Very well structure, with simple, easy to understand language, and excellent navigation.

I’d also like to mention the design separately. So often do technical people end up using generic templates that aren’t very well suited for longer texts, quotes, and code snippets. So often do designers overdo things making documentation nice looking, but impossible to read. Think Like a Git is not like that. It’s beautiful, yet clean, fresh, and simple. My eyes are actually resting while I flip through the pages. Nothing annoys or disrupts my attention. It’s all about Git. Bravo!

Branches graph at GitHub

One of my favorite features of GitHub (and, probably, pretty much any other git client) is the graphical representation of branches.  It usually gives a crystal clear picture of how the source tree came about to be.  But I think today I actually managed to confuse the heck out of it.  Have a look at the screenshot below.

A couple of commits ago it was a master branch (black) and a stable branch (magenta).  Then I (if I remember correctly) created a test branch from the latest stable, pushed it, switched to stable branch, reverted one commit, and pushed it as well, then added a couple of commits to master and merged it into test.  Pushed and got the thing above.  Weird looking source tree mutant.

Anyway, I’m sure it will sort itself out some time later.

P.S.: Indeed, as expected, after just a few more merges, commits, and pushes the tree sorted itself out.  Lovely GitHub, very lovely!

Debugging with git bisect

Via Sebastian Bergmann’s blog I’ve learned about git bisect and how it can used for debugging.  Sebastian demonstrates the functionality together with PHPUnit.  I am a git newbie, so that was quite interesting for me.

git bisect can be used to find the change that introduced a bug. It does so by performing a binary search on the list of commits between a known good and a known bad state of the repository. A tool such as PHPUnit can be invoked at each step of the binary search to check whether or not the current state is broken.

Here is a shortcut on how to actually use it:

$ git bisect start
$ git bisect good someVersion
$ git bisect bad someOtherVersion
$ git bisect run someCommand -with SomeArgument

There are, of course, more resources online covering the feature.  I found this section of the Git Community Book helpful.  Hopefully, I’ll remember about it when I actually need it.