Code history is like a narrated history of code. The ability for git rebase to reorder, rework and polish commits allow a developer (and code reviewers) to curate the code history so that it tells a well structured story. This post will wander through how strongly the analogy can work.
TL;DR version in the slides. Read on for the long form.
As developers we deal with regressions on a regular basis. Regressions are changes that are introduced to a system that causes a potentially unwanted change in behaviour. Engineers, being wired the way they are have a tendency to want to fix first, understand later (or understand as part of the fix). In a large number of cases however, it is considerably more effective to isolate and understand the cause of the regression before even diving into the code to fix it.
This is a continuation of a series of blog postings I am making on regression isolation and bisection, the first of which was “A Visual Primer on Regression Isolation via Bisection”. If bisection and regressions are terms that you don’t solidly understand, I strongly suggest you read the primer.
use-cases.org - Matthew Tippett's Blog 