[simula67]

Nothing about what was wrong about gitflow.

One small correction I would like to make to gitflow is that the default branch for developers should be 'master'. If you want to deploy another branch, use a 'production' branch. This means people don't have to manually change branches everytime they clone, that type of repetitive work should be outsourced to a computer ( your deployment scripts ). If you have full access to the repo and you are on github, atleast you can change the default branch ( which for a repo I contribute to, I don't )

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

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

[VLM]

Jenkins should always pass master. develop is for things that need to be done but necessarily mean Jenkins is at least temporarily very unlikely to succeed and thats "OK" or even "normal".

Or another way to put it is develop doesn't even have to compile. I mean, it would be nice if it does, but its OK if it doesn't.

master might not do what the end users think its supposed to do, but at least it compiles.

Or another way to put it is develop is for big revolutions and master is for small evolutions.

git flow releases are supposed to actually do what the end users think its supposed to do. Or it actually does what they've been told to expect.

It provides a natural flow of code, from a feature doesn't work but its worth a share, to it compiles but doesn't implement business required feature #1243 or feature #531, to we think it correctly meets the business needs at least as of one definition of need at one point. Or another way to put it is a separation of development process of develop to master from the business requirements of master to a release branch.

I suppose everyone uses it a little differently.

[bryanlarsen]

Note that you can change the default branch in github:

https://help.github.com/articles/setting-the-default-branch/

[sytse]

I fully agree with using master for development. I also think that the git flow process is over the top for most teams. I detailed how to adopt just the things you need in GitLab flow.

"you lost track of the comments in the code and viewing what had actually changed since the last update became really hard" I don't understand why comments in the code would disappear. Line-comments on the code might disappear when lines are changed. We're adding a feature to GitLab where you can acknowledge line comments. And viewing changes is pretty easy as long as you don't rebase.

[gregmac]

At work, we use master as you describe, and follow gitflow for feature and bugfix branches.

For release-to-customer products, we have a release branch, eg: release/1.2.3, and as part of our CI build, that number is automatically picked up and used in the product itself as the version number.

For our cloud/SaaS/single-instance stuff, we have a 'staging' and 'production' branch, and typically have 3 environments (dev, staging/test, and production) all of which are continuously deployed. We typically just do fast-forward merges to bring staging and production up-to-date with master.

In both cases, when a developer is working on a new feature or fix, we want them to base off master.. which is the latest fully-integrated build, though it hasn't passed QA. If they worked off a production/release branch, we'd continuously have to deal with conflicts as by definition they're basing their changes on out-of-date code.

A 'develop' branch could work for some of our small stuff, where typically production/release isn't far off from master, but for our main stuff we do a 2-3 month release cycle, so master usually has quite a lot of changes that aren't in release.