145

I've noticed something lately looking at some popular projects on GitHub, that there's no develop branch. And in fact, the GitHub Flow guide doesn't mention it either. From my understanding, master should always be totally stable and reflect production. If developers are working on feature branches, and then merging those into master when they're done, that means there's a period of time where features/fixes are being merged into master and the master branch is actually newer than production.

Wouldn't it make more sense to have the team create feature/fix branches off of develop, merge back into that, and then when the next version is totally ready for release, develop is merged into master and a tag is created? Imagine if people are merging straight into master, and a bug is reported in production that becomes difficult to fix because the master branch codebase has changed significantly. Then the devs just have to tell the user to wait until the next release to see the issue resolved.

EDIT: This question is different than "to branch or not to branch." It specifically addresses people moving away from using the develop branch and the reasons surrounding that, since that was touted as a best practice for a long time.

ffxsam
  • 1,591

6 Answers6

77

It comes from the CI mindset where there is integration several times a day.

There are pros and cons of both.

On our team we have abandoned the develop branch as well since we felt it provided no additional benefit but a few drawbacks. We have configured our CI software(Teamcity) to compensate for the drawbacks:

  1. Enable deployment of a specific commit. In other words: We don't deploy a branch. We deploy a commit.
  2. We can deploy either master or branches starting with a hotfix/ prefix.

The reason this works is because all pull request contain potentially releasable code but this doesn't mean we deploy all commits in master.

The main reason we abandoned the develop branch is because it tended to get too large and too time consuming to see what it actually contained. If we have deployed something a little prematurely we just branch off a hotfix branch and deploy that directly.

JoelFan
  • 7,121
Esben Skov Pedersen
  • 5,168
37

There are two philosophies I've seen in projects, and I think the choice is just a matter of taste:

  1. Designate 'master' as the production release and develop in a 'develop' branch.

  2. Develop in 'master' and have a differently-named branch for stable production releases. This makes even more sense if your project has multiple release branches at a time (e.g., the current preferred one is Release-1.8, but you also are still maintaining Release-1.7).

Both are common approaches, and have their pros and cons.

Larry Gritz
  • 541
33

A develop branch matters more if your process to release is complex and you need to have serious release-candidates.

For example, imagine you are writing software which is firmware on cars. This is... non-trivial to fix and it is likely any release would have a comprehensive set of non-CI/integration tests run on real hardware.

In that case it may make more sense to isolate a "release candidate" in a non-master branch (such as "develop"). That allows your team running those tests to have a branch to merge features into.

Webapps or other easily updated software do not have this constraint.

However, note that:

  • Many (most?) projects on github do not have this sort of constraint
  • A main "master" serves the same purpose
  • A workflow of "make a PR vs master" is far more universal than "make a PR against a branch that you don't know immediately on this repo"
enderland
  • 12,201
  • 4
  • 53
  • 64
15

If developers are working on feature branches, and then merging those into master when they're done, that means there's a period of time where features/fixes are being merged into master and the master branch is actually newer than production.

...

Imagine if people are merging straight into master, and a bug is reported in production that becomes difficult to fix because the master branch codebase has changed significantly.

That's not Github Flow.

This is the Github Flow deploy/merge process, according to your link:

Deploy

Once your pull request has been reviewed and the branch passes your tests, you can deploy your changes to verify them in production. If your branch causes issues, you can roll it back by deploying the existing master into production.

Merge

Now that your changes have been verified in production, it is time to merge your code into the master branch.

(Emphasis mine)

In other words, master will never be ahead of production. Similarly, master will always be in a stable, releasable state (aside from undiscovered bugs), since everything is reviewed, tested, and rolled out to production before being merged to master.

8bittree
  • 5,676
  • 3
  • 29
  • 38
10

Releases to production can be tagged, so the situation that was released can always be reproduced without devoting an entire branch for this purpose.

If a critical bug is found in production at a moment when master can't be released, then it is easy enough to checkout the tag and start a new "hotfixes-for-release-1.2.0" branch from there. But that should be rather rare.

Most of the time in our web applications, master has changed since the last release but not very significantly, so we can simply do a new release from master that has the fix. It helps to do very frequent releases anyway.

RemcoGerlich
  • 3,330
  • 20
  • 24
5

The issue I see is that Git/Hub flow deploy/merge assumes one feature is being developed/tested/merged/deployed at a time - and often in my experience this isn't the case. If we merged a feature at a time, there is a larger chance for regression issues - only found after the features are merged to master and possibly in production.

There needs to be a way to test multiple features, merge multiple features and deploy the same. I've been using a 'bundle branch' (a branch created from master with test ready feature branches merged into it) that gets deployed to qa/uat. Corrections during uat happen on the feature branch only, and those get re-merged to the bundle branch. After a subsection of the bundle branch is approved, only those approved features within the bundle get pull-requested to master - and the cycle is continuous.

I use this with Gitflow, but pondering to use it for GitHub flow. The QA/UAT many feature at a time issue seems of significance. Another issue with GitHub flow is it assumes all sr developers, and that is not always the case.

I would rather use the GitHub flow due to its simplified-ness. With a bundle like feature, I think it would be better ready. I'ts possible the bundle is similar to release; however, I am still pondering this as well.

Another issue is the pull request process happens at the end before merging to master; however, sometimes you want to code review prior to the business qa testing - hence well before the merge

David Latty
  • 71