Git Branches Considered Harmful

One of Git’s most popular features is its branches. Almost all projects that use Git use branches, and the selection of the “best” branching strategy is like a rite of passage for an open source project. Vincent Driessen’s Git-flow is maybe the best known. It has base branches (master, develop), feature branches, release branches, hotfix branches, and support branches. Many teams have adopted Git-flow, which even has Git extensions to support it. I’m a great believer in popular wisdom, but sometimes you have to recognize mass delusion for what it is.

Here is a section of C4 that might have shocked you when you first read it:

The project SHALL NOT use topic branches for any reason. Personal forks MAY use topic branches.

To be clear, it’s public branches in shared repositories that I’m talking about. Using branches for private work, such as to work on different issues, appears to work well enough, though it’s more complexity than I personally enjoy. To channel Stallman again: “Your freedom to create complexity ends one inch from our shared workspace.”

Like the rest of C4, the rules on branches are not accidental. They came from our experience making ØMQ, starting when Martin Sustrik and I rethought how to make stable releases. We both love and appreciate simplicity (some people seem to have a remarkable tolerance for complexity). We chatted for a while... I asked him, “I’m going to start making a stable release, would it be OK for ...

Get ZeroMQ now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.