[davnicwil]

> Anyone know the need for a seperate 'develop' branch

The HEAD of master should always be production-ready code. It is your most-stable branch.

It's necessary to have a less-stable, separate, develop branch where features, bugfixes, etc, that were developed off on their own sandboxed branches can be merged and integrated as part of a development phase.

Even with the most disciplined testing of isolated feature branches, it's not known whether integrating different ones will always work, so it is not even guaranteed that the HEAD of develop will always be stable, let alone production-ready. Even if it is stable, it could not be production-ready for the simple reason that it so far only contains features X and Y, and the next release cannot go out without Z there too, where Z is not merged yet.

As you point out, having master as the most stable branch appears to just be a convention, and it would be perfectly possible to branch a production branch from master and swap the roles at the start of the project too.

I think the convention is like that so that one can immediately build and run the latest production code after cloning the repo, which in my opinion is nice. Besides, with the number of branch switches you do every day as part of normal development, it doesn't seem too horrible to have to do it once, to start working off of develop after you clone the repo - at the end of the day how often do you do that, and how annoying or arduous really is it?

[mbell]

> It's necessary to have a less-stable, separate, develop branch where features, bugfixes, etc, that were developed off on their own sandboxed branches can be merged and integrated as part of a development phase.

I don't think it's _necessary_ by any means. e.g. We auto-deploy the HEAD of master, assuming tests pass and don't use any special integration branch. If you have some set of features that need to ship together, that is just a feature branch like all others. Multiple people can work on a feature branch and test their integrations there.

> Even if it is stable, it could not be production-ready for the simple reason that it so far only contains features X and Y, and the next release cannot go out without Z there too, where Z is not merged yet.

I think largely your assumptions are based on a slow moving release cycle, not everyone operates that way. We regularly release multiple versions a day in most of our repos.

[davnicwil]

Within gitflow it is definitely necessary to have an integration branch - it doesn't really matter if you call it develop, or you progressively merge different features branches down together, or group them into one feature and just develop them all on one feature branch from the get go, the result is the same - you end up with all your code integrated on one, not necessarily always stable, branch.

The idea in gitflow is that you then isolate a snapshot of that integration branch, whatever form or name it takes, as a release branch, and only when that release branch produces a build passing all tests is it then merged to master (and probably tagged).

You mention you auto-deploy from HEAD of master after tests pass - does that mean that code at the HEAD of master may not pass tests, or that you merge code to master only if it has passed tests. If it's the former, then you're not using gitflow, and I was just explaining the use of separate master and develop in gitflow, not implying that this is the one true branching/release strategy. Using something other than gitflow can work equally well. If the latter, then you are using an integration branch - the one you run the tests on before merging to master.

As to the point about release frequency, having a set of features to release in batch was just an example - if you're in any situation where other developers may commit things to the branch that will ultimately be released from between the time you create your feature branch and the time you merge it, then gitflow is useful - be that on a scale of minutes, hours, days or weeks.

[klibertp]

> It's necessary to have a less-stable, separate,

...ok, I guess...

> develop branch where features

...what? Why shouldn't I call my branch for integrating code... integration, or something?

> I think the convention is like that so that one can immediately build and run the latest production code after cloning the repo, which in my opinion is nice.

It's not nice; it's wrong. Who is going to checkout a project code? End users? If so, then it makes sense. However, if it's just developers, it's fair to assume that they do the checkout to develop the project, and so making master a production branch gets in their way. A very typical scenario is when a new dev joins the project, hacks happily on branch forked from master and finally submit the PR with fixes which were already done, and probably already done in a different way, so you have both time wasted and merge conflicts. Don't do that! At the very least set your develop branch as the main one on GitHub, but that's still not as idiot-proof as just using master for development and separate branches and/or tags for production releases.

[davnicwil]

> Why shouldn't I call my branch for integrating code... integration, or something?

You can :-) gitflow is just a pattern, the names of the branches are an implementation detail. Just using develop here as it's the name used in the parent's question.

> A very typical scenario is when a new dev joins the project, hacks happily on branch forked from master and finally submit the PR with fixes which were already done..

Gitflow like any branching strategy requires that people using it understand it first, to work. Obviously it's always better to craft these things in ways which help people fall into the pit of success, but if you have new devs just cloning a project, branching however they assume is ok and then fixing bugs that others are working on etc, without once asking a question or being instructed in even the simplest way on what to do (saying 'we use gitflow on this project, development branch is called X' in the readme for example), that's a problem that no branching strategy is going to solve!

[daxfohl]

A common case where this doesn't work well is embedded code. You'll frequently have many different releases of your code "in production" at the same time.

I started an embedded project a while back using the gitflow style I was used to, but eventually found the meaning of "master" to be not well defined, once we had different release versions and variations. We eventually killed master, and renamed "develop" to "master", and that particular project makes much more sense now.

[davnicwil]

That makes sense, but I don't understand how renaming the branches made that problem go away.

Also, if you had different variations of builds etc (I assume for different target hardware) could it have been better organised by putting all the common code in a different project, then creating separate projects for each of the variations with that common code as a dependency? Then you could probably manage each of the variation projects with gitflow as usual.