So, we're going the gitflow way [1][2]. However, when I looked at our bitbucket
repositories today, only the libtaskotron branch uses 'develop' branch, all other
projects use only 'master' branch - even taskotron-trigger or task-rpmlint. Does
it mean we use gitflow only for libtaskotron? Or is it a repo author's choice? I'm
a bit afraid it's going to be chaos - you'll need to inspect available branches
every time to decide against which branch to base a patch or into which branch to commit.
I wonder, could we use gitflow but drop the idea of misusing 'master' branch name
for something else than usual?
Because that's the main grievance I have against gitflow, otherwise it's a neat
workflow. I believe gitflow should have never used master for something else, it should
have used 'stable' branch instead for stable releases (i.e.
'gitflow/master' should have been 'traditional/stable' and
'gitflow/develop' should have been 'traditional/master'). All the tools
(and most of the users) expect 'master' to be the main development branch. Git
init creates master by default. Git clone checks out master by default. Github/Bitbucket
displays master by default. Arcanist merges to master by default. Users clone and send
patches against master by default. Usually you can adjust the tools, but what's the
benefit? Why all the mess? I simply don't get it. (Also notice people criticizing it
under one of the most famous blogposts [3] and offering the same suggestions as I do).
So, if we use gitflow with traditional master meaning, and stable branch for stable
releases, I see it as a win-win. Regardless whether that particular repo uses gitflow or
not, you known what branch to work with automatically. You don't need to change
configuration in your tools. Everything works, and you get the benefits.
If you have installed the gitflow RPM package (it adds the "git flow"
subcommand), it asks you initially what naming conventions you like to use. So if you like
that tool, there's no problem using it with the traditional 'master' meaning.
[1]
https://fedoraproject.org/wiki/User:Tflink/taskotron_contribution_guide
[2]
http://nvie.com/posts/a-successful-git-branching-model/
[3]
http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/