Git-flow and master with multiple parallel release-branches
Solution 1:
In the git-flow model, your "latest released" version actually maps to the master, while your "preview release" maps to a git-flow release branch. It is forked from develop and finally merged into master when the actual release happens. Then this will become your "latest release" and you will usually fix only bugs for that release, using git-flow hotfixbranches. In this way, your master always represents the most stable state of your latest released version.
If you want to fix bugs for older releases or do any other develop there, you will fork a support branch from the appropriate commit in master (you will have all versions ever created there). support branches are still experimental (according to the docs) and are not well documented. But as you can see from the command line help:
usage: git flow support [list] [-v]
git flow support start [-F] <version> <base>
these branches are just started and not intended to be merged back to master nor develop. This is usually fine, as fixes to "ancient" releases or features requested by customers to be implemented in "ancient" releases can't or should not go back into master. If you still think, you want to port a fix to your main development line (represented by master and develop), just start a hotfix, cherry-pick your changes and finish the hotfix.
Solution 2:
Looks like mostly a mental model with a bit too much emphasis on branches. I agree, you could just tag the commits you release instead of merging them back into master.
The picture is pretty, though. Merging everything back into master gives a clear indication of the releases in temporal order instead of having version tags strewn all over the graph.
I think this model does not work for bugfixing in older releases, though. It messes up the neat ordering.
- Say we have released Version 1.0.1 and later added features and released 1.1.0.
- We discover a bug in 1.0.1 and want to fix it in both version
- We have to add 1.0.2 after 1.1.0 in master and then directly atfer (or before) also 1.1.1.
To answer your question: I think this is a set of rules that makes for a simple mental model in some cases. Not all of the rules make sense from a purely technical point of view but that doesn't make them bad. Mental models be good for 'em humanses.