On Fri, 24 Jan 2014 10:03:40 -0500 (EST)
Kamil Paral <kparal(a)redhat.com> wrote:
So, we're going the gitflow way . However, when I looked at
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.
There are multiple reasons for this:
1. gitflow probably isn't appropriate for tasks. if we're cloning the
repo with automation, the only thing that I can see using branches for
is to differentiate between releases
2. trigger was pushed up as proof-of-concept code and I forgot to add
a 'develop branch'
I wonder, could we use gitflow but drop the idea of misusing
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  and offering the same suggestions as I
I disagree with you here - master is the main branch but it isn't
necessarily the main "development" branch. I see it as folks cloning
a repo and wanting it to work, therefore having stable release code in
master makes more sense than having the stable release code in some
I guess it comes down to who we want to prioritize as the "default"
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.
Until we get folks who are used to the default gitflow config (note
that infra is using it for many of their projects) and confusion may
If you have installed the gitflow RPM package (it adds the "git
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.
I still disagree with you about the "traditional" meaning of master.
While many projects seem to use master for dev, I think most of those
projects don't have separate dev and release branches.
That being said, I'm not completely against this idea if there are
enough other folks who are +1. I'm still -1 on the idea but I could
live with it :)
If we do change the defaults for gitflow, let's do it soon, though.