A monolithic dev branch

At the recent XO Ruby Vancouver event, Ryan Davis (zenspider) gave a talk called “Git Power Tools.”¹ I would recommend it to any beginner or intermediate Git user whose team a) collaborates on a large codebase, b) collaborates using a rebase workflow, and c) values atomic commits and the writing of good commit messages.² Before I get into the most valuable idea I took from Ryan’s presentation, the monolithic dev branch, I want to summarize what, at a macro level, I think makes this talk insightful.

A brief summary

Ryan walks us through his process for debugging a set of commits. Throughout, he uses an example of a feature branch with a lot of changes: a big upgrade to a web application that needs to be deployed all at once. (It happens.) The process is centered around using git-bisect to locate the first commit that introduces a bug. Then, he uses a variety of Git’s other tooling to split up, reorder, and rewrite commits. The talk includes a link to a repository of aliased Git commands and scripts that allow him to rapidly chunk and reshape history. His goal is to isolate the code that works from the code that doesn’t. He digs out suspicious chunks of code and refines the good code until it works without the bad code. His process is effective for him because of his very-refined power tools. They do broad, tedious things that he would otherwise have to do manually with a chisel.³

The dev branch

Now, the monolithic dev branch. How does this idea fit into Ryan’s talk? His example, remember, uses a well defined upgrade feature branch. A monolithic dev branch is something else.

Ryan describes that he typically uses a local branch off a repository’s main branch, maybe called dev, where he stores commits that fix things, or are useful to him locally, but are not relevant in the context of the current work being done. (In the Q&A after the talk, Ryan reiterates that this is a local branch he grooms and rebases against the main branch regularly.)

While debugging a broad set of commits on an upgrade feature branch, I can see the value. Ryan’s process is about refining and re-refining the set of commits. Based on my own experience, it’s possible to realize that a change is valuable but not essential in the context of the current branch. There may not be another well defined branch to put this inessential commit on.

The advantages

So, the advantage of the monolithic dev branch is that it’s a branch where one can store known good commits⁴ that don’t have a well defined branch yet. And back to the checkout of your feature branch, you’ve succeeded in dropping a commit and reducing the count of lines you need to test and verify before you can merge your upgrade branch. You have reduced how much you need to explain your changes to others (and your future self). You have reduced the count of lines your colleagues need to review before merge. You have just isolated some good code to be out of scope.

To me, there’s another advantage. The more integral that this dev branch becomes to your workflow, the less likely you are to lose track of bugs you’ve fixed, improvements you’ve made, and so on, that are valuable, but currently out of scope. These changes you’ve made, each one in isolation, are less likely to rot stored cumulatively because the monolithic dev branch is a branch you keep well groomed. These changes maybe haven’t been ticketed out yet, or are changes you’re still thinking about, or are changes that are still thinking about you.