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.

  • 12
    There are many possible workflows that git enables. One shouldn't expect gitflow or github flow to be used for all projects. – user40980 Mar 7 '16 at 19:38
  • Very interesting question. I have worked years with the nvie.com/posts/a-successful-git-branching-model and I have to say that I like it. What I like most about it is that a) master is what s on production and that applies also for versions and b) there is a clear difference between a hotfix and a feature, they are initiated and merged on master and develop respectively. However, after following this discussion I start having doubts whether it is overcomplicating things. Any opinions on that? – Aspasia Sep 13 '17 at 15:37
  • 4
    I hate the concept that master is a record of what is in production. If we need to know what is in production, we should just query production and not rely on master accurately reflecting what is in production. – Jim V Jun 11 '18 at 23:29
  • 1
    @JimV If none of your branches reflect production how could you ever create hotfix branches? Relying on a production server as an authoritative source for development seems like a really bad idea. You server could corrupt files or a hacker can insert a backdoor, and your repo would be infected. If it's not in the repo then it might as well not exist. – AyexeM Nov 9 '19 at 4:20
  • 1
    @AyexeM from the commit that reflects production, create the hotfix branch. – Jim V Nov 9 '19 at 6:48

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.

| improve this answer | |
  • 17
    Having worked with a develop branch for a year or two, just to have it merged into master every now and then, I can just say: amen, abandon that thing :] – stijn Mar 7 '16 at 21:06
  • 1
    Interesting. So I assume when you release version 1.3 for example, you tag a specific commit on master, so you if a bug arises later while master is in a state of flux, you can easily branch a hotfix off of the 1.3 tag? – ffxsam Mar 7 '16 at 22:06
  • 6
    I'd say the benefit of "develop" depends heavily on what kind of software you're making, how it's deployed, and whether you need to support multiple live versions or not. – axl Mar 8 '16 at 0:30
  • 3
    @ffxsam we don't even need tagging because we are tracking which git id is currently deployed. This is logged in both TeamCity and branched into deployed dll's and in azure management portal. So we have not felt the need for further tagging except from the automatic tagging done by TeamCity. If you feel tagging fits you work flow better it would also solve it nicely. But yes, in principle branch off directly from the currently deployed change to make a hotfix branch. – Esben Skov Pedersen Mar 8 '16 at 7:05

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"
| improve this answer | |

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.

| improve this answer | |
  • I agree with you. We prefer to have release branches and maintain those around until the next release to production. If we have to make any hot-fixes, we checkout the last release branch and work on that, then merge those hot-fixes into master/develop branch – Johnny Aug 30 '18 at 18:27
  • Exactly. What 'master' should do is mostly semantics. The fundamental thing to get right is avoiding having to keep multiple forever-living branches bi-directionally sync'd unless you have a really good reason to do so. The 'master' branch in Git Flow is just a lagged replica of 'develop', so it doesn't really count. The anti-pattern is allowing the main development branch to hold changes that never go into a release, which is a shockingly common practice I've seen. Both models mentioned above prevent this, which is why they work. – John Michelau Mar 26 '19 at 21:29

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:


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.


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.

| improve this answer | |
  • 1
    Nice! This makes great intuitive sense - master is always your rollback position if the feature branch you push into production fails. If it doesn't, it gets merged into master and becomes the new fallback. I like it. – Bill Horvath Jul 12 '19 at 19:06
  • 1
    I've always merged into master before pushing into production, which after reading this I'm realizing that's a mistake. – AyexeM Nov 9 '19 at 4:23

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.

| improve this answer | |

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

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.