Git-Flow works very well for a scenario where devs mantain & evolve a software with a single instance on production (i.e. http://www.virgingames.com).
But imagine a scenario where devs develop a software that has different versions installed in different clients and devs have to give some support to old versions. (i.e. Visual Studio) while evolving the latest. Devs have to:
- Mantain version 1.0 of your software (critical bug fixing) [In our example VS 2013]
- Mantain version 1.1 of your software (critical bug fixing) [In our example VS 2015]
- Develop version 1.2 (new features) [In our example VS 2017]
Git-Flow doesn’t support that scenario. Here is my solution, a git flow variant with feature branches and multiple “Master” branches called Release Branches.
- Feature Branches and Dev branch works like git-flow.
- Version 1.0
- First release (r1.0) is done by creating a branch.
- Evolutive development continues in Dev branch (and feature branches)
- It is critical that no evolutive development is done in Release Branch r1.0 so if user wants a new feature he has to wait to r1.1 version.
- If a critical bug is found in r1.0 version it can be fixed there.
- If the critical bug is affecting dev, bug fix must be merged to dev branch.
- If the critical bug is complex a small hot-fix branch can be created (like a feature branch)
- Version 1.1
- When next version (r1.1) is ready a new branch is created [Same as previous version]
- Old branch (r1.0) is kept while we have still users on that version.
- Once version 1.0 (r1.0) is declared obsolete, users with bugs must install a higher version.
- Version 1.2
- Same as version 1.1