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