gitflow and branch naming conventions

[Tim Flink]

On Thu, 30 Jan 2014 07:56:08 -0500 (EST)
Kamil Paral <kparal at redhat.com> wrote:

<snip>

> > 
> > > And it's kind of
> > > superficial anyway, because why would you check out a branch
> > > containing only tagged commits? In git you can check out a commit
> > > directly.
> > 
> > How would you integrate any changes to that commit without making an
> > unholy mess of the repo or releasing it as a patch?
> 
> Exactly the same as in the original gitflow model - by using hotfixes
> branch. See the picture at [1].
> 
> Let's say you find a problem in tag 0.1. You create hotfixes/0.1
> branch starting from commit 0.1. You fix the problem in one or more
> commits. Then you tag the last commit as 0.1.1 or 0.2, as you wish.
> Finally, you can delete hotfixes/0.1 branch, it's no longer necessary.
> 
> Then you discover problem in tag 0.1.1. You create hotfixes/0.1.1
> branch starting from commit 0.1.1, fix the problem, tag the latest
> commit as 0.1.2, delete the branch.
> 
> Of course all those hotfixes get merged into your development branch
> as well. Everything is the same as in the picture. I was just trying
> to point out that the rightmost thick line connecting tags 0.1, 0.2,
> 1.0 and so on (a branch called master on the picture) is not
> necessary at all. The only "advantage" it has is that it allows you
> to do "git pull" to get the latest stable release instead of checking
> out a tag directly ('git tag' and 'git checkout <tag>'). 
> 
> However, since you don't agree with master referring to development
> code and you rather want master to refer to the latest stable code
> (something I haven't expected before), then yes, the original picture
> in the article makes sense in this case. If you intention is to offer
> people the latest stable code by default (when they open up our
> github/bitbucket page, they are shown master as the default branch),
> it all makes sense and the branch is needed. (That's not what Fedora
> Infra does, however, they display 'develop' branch as default for
> many of their repos; that defeats the purpose of the rename in the
> first place).

I think that a lot of this stems from my misunderstanding of your
proposal. I thought you were proposing to merge the 'master' and
'develop' branches into a single branch, which is not what you actually
proposed :)

Honestly, I don't care much whether we change the default branch for
the repos or switch the way we're naming branches. I'm more interested
in maintaining the separation between stable and development branches,
do hotfixes etc.

The biggest impediment I see to changing the branch names is that we'd
have to go back and change blockerbugs (using gitflow with default
names) but I suppose that's not a huge issue.

<snip>

> > I'm not as worried, to be honest. We need to document our processes
> > better but in a similar vein to what I said about github and making
> > drive-by patches easier, if someone is not capable of looking at the
> > readme or any other docs before writing a patch ... are we really
> > that confident that any contributions would be useful and wanted? If
> > reading the readme and typing 'git checkout develop' is too much
> > work for testing, how likely is it that the same person would take
> > the time to file a decent bug or send mail to the list?
> 
> I agree with you, people will need to read documentation anyway. The
> only thing I dislike is that we want to divert from the traditions
> that everyone knows. 'master' is traditionally used to mean the main
> development branch, or at least _a_ *development* branch. If we want
> to have a branch with just stable, released code, why wouldn't we
> call it 'stable' (or anything similar) instead of changing the
> meaning or 'master' and then using a different branch for the
> purposes of master?
> 
> But I don't think we should spend too much time on this. If you
> believe that we should go against the tide and have 'master' to mean
> something else, I'm fine with that. I simply did not expect that this
> is really your intention.

Agreed on not spending more time on this. We've got more important
things to deal with than branch names.

> > 
> > It'd be nice to hear some more opinions on this - especially
> > from folks who will be regular contributors (don't make me call you
> > out by name because I will resort to that if needed).
> 
> I think they are a bit discouraged by the long discussion and they
> don't want to wrap their brains around all those graphs and models.
> I'm not surprised, I did not expect to go into so much detail anyway,
> for me this was a trivial rename fix proposal. But apparently I
> wasn't able to describe properly how simple all of this is, and it
> evolved into such a complex monster issue :-) I'm fine with anything,
> really.

Yeah, I'm fine with either changing the default branch or renaming
stuff - as long as we do it for all projects and do it very soon.

After talking on IRC, I think we're both OK with changing the default
branch in bitbucket. It takes the least amount of work to change and I
suspect it'll mean less documentation and confusion since we'd be able
to use the defaults during gitflow setup (assuming folks are using
the gitflow tool). People landing on the bitbucket page will see the
devel code which makes sense to me and if I'm understanding you
correctly, was your main objection to gitflow.

Any objections to going forward with this - setting 'develop' as the
default branch for projects which are not dependent on fedora version
and keeping with the gitflow defaults?

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/20140206/6c9b940d/attachment.sig>