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.
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.
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.