December 02, 2016 • 1 min read
I just built a new project, called ‘Git Bisect Demo’. It’s available here.
The purpose of this program is establish conditions where a Git Bisect would be a useful problem solving tool.
I built this application for next Tuesday’s Git-themed Vim Chicago Meetup
(link). I plan to
git bisect for the attendees.
git bisect is an obscure yet essential command.
git bisect conducts a binary search through your Git history to identify when
a change was introduced to the codebase, supported by automated or manual
As a consultant and OSS project maintainer, this command is essential. It’s the best answer to the question: ‘when did this break?‘. And also, ‘who broke this?‘. Usually, the answer is: ‘me’.
But bisect isn’t about blaming or praising a certain commit. It’s about isolating problems, fixing them, and learning.
This was a puzzle: how do I reproduce a situation where something has failed,
but the reason is unknown? My solution was to build a mix project with a module called
HelloWorld and test that
makes incomplete assertions about its behavior. If you’ve ever had code that
you thought did something, but that thing wasn’t covered by a test, this is that.
For a bisect to be worthwhile, we need a decent size of commits. So, I piled on a dozen refactor commits. While also breaking the untested functionality.
My final commit simulates the ‘aha’ moment when the team realizes that something we thought worked does not, and smartly writes a failing test.
With these conditions, a bisect is possible. Commits where the test passes are ‘good’.
In an upcoming post, I plan to review the presentation. Thanks for reading.
Each week, I write an email about React. It's a collection of quotes, news, conference talks, and documentation curated be me to help you get up to speed on this exploding ecosystem. Join my subscribers today by subscribing to React Explained.