gitflow and branch naming conventions

[Tim Flink]

On Fri, 24 Jan 2014 10:03:40 -0500 (EST)
Kamil Paral <kparal at redhat.com> wrote:

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

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

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
non-default branch.

I guess it comes down to who we want to prioritize as the "default"
consumer.

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

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

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.

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/qa-devel/attachments/20140127/645fabca/attachment.sig>