gitflow and branch naming conventions

[Tim Flink]

On Mon, 27 Jan 2014 14:24:35 -0500 (EST)
Kamil Paral <kparal at redhat.com> wrote:

> > 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 think 'master' should always contain the latest _working_ code. If
> we want to take something apart and break it, it should be developed
> in a feature branch. And functional tests should be run on every
> commit to master. (I know, that's the ideal state, but it seems we're
> going the right way).
> 
> If somebody wants a stable code base, he usually doesn't clone
> master, does he? He checks out a stable tag instead.

I suppose it depends on the person. If I'm going to poke around at a
project, I usually do so with master. Then again, if I'm going to
package something, I look for a released download which generally
corresponds with a tag (which it should, regardless of branch strategy).

> > I guess it comes down to who we want to prioritize as the "default"
> > consumer.
> 
> What are the choices? I think the most common consumer for master
> branch is a developer or, alternatively, an experienced bleeding-edge
> user.
> 
> > 
> > > 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 there's no develop branch, what confusion do you refer to? I see
> gitflow as a set of SOPs - branching procedures and naming
> conventions. You can easily follow it and nobody doesn't even need to
> recognize that you use gitflow. You just name your feature branches
> 'feature/XX', release branches 'release/XX', etc. I'm not sure how we
> can confuse people, if our repo consists of 'master' and a bunch of
> 'feature/' branches.

Yeah, it's a set of SOPs but they also come with default values - the
develop branch being one of those defaults. I assume that people could
figure it out but that's pretty much counter to the argument that
you're making (people would not notice the develop branch and send
patches against master).

> > > 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.
> 
> They don't and they should, but I don't see this related to
> develop/master naming issue.

Naming has little to do with it. You could call the development branch
"snozberry" and the released branch "maplesyrup" and the argument would
be pretty much the same. It's about separation of released and
under-development code in consistent places.

> If I understand you correctly, you would like 'master' to contain
> more stable code than what is usual for a large number of existing
> projects - broken code, incomplete features, failures to even
> compile, etc. And that is a nice goal indeed. I think we can achieve
> that either by: 1. strong development practices - feature branches,
> commit reviews, continuous integration tests or by: 2. not bothering
> with strong development practices and putting all dirty work into a
> separate development branch (let's call it 'develop') that's going to
> be broken most of the time. However, every time the code starts to
> look better (it compiles, tests pass), we promote it to master.

2. is not acceptable in any way, shape or form. The development branch
needs to be usable almost all of the time and we should be deploying it
to a dev system on a regular (every couple of days, bare minimum) basis.
Regardless of what we call the different branches, the only place it's
acceptable to have regularly broken code is in a feature branch.

> Of course 1. is better than 2., but it would be nice if those
> aforementioned bad projects adopted at least approach 2. The result
> is that people interested in bleeding edge code have working master,
> and even if they send a patch against master and 'develop' is used
> for the actual development instead, usually those two branches are
> not that far apart.
> 
> Unfortunately, that's not what gitflow does. In gitflow, 'master'
> means *the* stable, it means old code.

No, it means "production ready" code. While that is going to be older
than whatever we're currently developing by definition, it's not like
develop is rawhide to master's epel. It's a consistent place to get
stable code from if you chose to deploy from git or are working on a
bugfix against the currently released version that can't wait for the
development branch to be ready for release.

> It's not continuously updated
> from develop branch, it's updated only at releases. It's not the
> branch you want to receive patches against.

Why not? If the fix is for a bug in master, wouldn't we want the patch
against the released code instead of against code which hasn't been
released yet?

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

> I think this part of the workflow was created with some
> older SVN-like systems in mind, not git.

This workflow would be insane in SVN, branching and merging are
expensive and tend to be painful.

> So, in gitflow a 'master'
> doesn't mean 'unbroken code', it means the most stable code you can
> ever get.

Exactly - it's stable code. The methodology provides a clean and well
defined way to make changes to both stuff that's been released and stuff
that hasn't been released yet. I'm not saying that gitflow is the only
answer or that there aren't other ways to manage branches, I just think
that it's a good, relatively well-defined solution and I don't really
have a better alternative.

> So, it depends what you want to have. If you would like 'master' to
> mean 'unbroken/more stable code', I think gitflow fails to deliver
> that. If you would like 'master' to mean 'you can't get any more
> stable', then gitflow is perfect. But I really don't think that this
> is a common understanding.

Well, gitflow or any branching strategy isn't a cure. It's simply a
methodology that takes any guesswork out of where code should go or
what's in various branches. Without discipline and good development
practices, it's worse than useless because we'd have multiple branches
with an unclear purpose instead of just one.

One of the biggest advantages I see in having a 'develop' branch is
that new features don't have to come to a halt at release time. If we
combined master and develop, new features can't be merged in once we
start the pre-release process. How do you propose we do release
branches without a separation between develop and master? 

How would hotfixes work if we find critical bugs in released code
when our development branch isn't ready for release? How would the
gitflow tool be affected? Can it handle stable and development branches
being the same?

> > 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 :)
> 
> In that case it will depend on what others think (or if they voice
> any opinion at all). Of course, I could live with the default gitflow
> as well. I just simply find confusing and a bit irritating its choice
> to rename traditional branch names for no apparent reason or benefit
> (in my view). I can definitely cope with it, sure, I'll remember what
> branch name to use. But I'm concerned about the passers-by and
> potential bleeding-edge users/contributors. I see this as an
> unnecessary bump on the road they need to hop over.

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?

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

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/20140129/0bfa46a8/attachment-0001.sig>