gitflow and branch naming conventions

[Kamil Paral]

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

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

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.

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. 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. 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. I think this part of the workflow was created with some older SVN-like systems in mind, not git. So, in gitflow a 'master' doesn't mean 'unbroken code', it means the most stable code you can ever get.

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.

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

> 
> If we do change the defaults for gitflow, let's do it soon, though.
> 
> Tim
>