Dirty Release Branch

In the past, I've presented a branching model that can be termed as the "clean" branching model. The basic idea was you fixed a bug or implemented a feature in the oldest, still active release branch, and merged forward.

In this post, I'll present the "dirty" branch model, where we do the opposite, kind of. This method seems to be quite popular among git users, with their emphasis on patches, and git's built-in support for handling patches.

In this model, all fixes and features are always first introduced on the main branch. A release branch is cut at some convenient moment, and is treated as a dead end branch. You do "whatever it takes" to slog the code into a releasable shape, knowing that none of the last minute hacks or reversions will be merged back into the main branch.

Bug fixes which affect ongoing development must be made on the main branch, and cherrypicked or patched into the release branch.

When the release is done, the branch is closed. A new branch including all the latest features is then created, and the hack/revert process begins again.

The advantages of this model are:

• You can revert at will. Nobody cares, and there is no risk of the reversion being merged back into an ongoing development branch.
• There are no big merges. This comes at the expense of occasional difficulties applying patches correctly, especially if those patches rely on reverted or non-existent code in the release branch.
• You can do quick hacks ("whatever it takes") and be safe in the knowledge that their lifespan will not extend past the current release.
• The change history along the main branch is cleaner and more linear, as there are no merge commits.

The decision flow for a developer is a lot more localized to the task at hand, and there is less environment switching involved.

There is, of course, a major drawback: refactoring code will make the patch process difficult to use.

This process works well for mature code bases that run mostly in maintenance mode. 

[update] slight grammar fixup.