Yeah, we also use something like this for building a website/webapp (for a client) with 5-10 people.

- Feature branch: do whatever you want

- Develop: should be good enough for the client (product owner) to look at

- Release branch: should be good enough to be tested by the test/QA team

- Master: should be good enough for website visitors

Branches are meant to be shortlived and merged (and code reviewed) into develop as soon as possible. We use feature toggles to turn off functionalities that end up in develop but can not go to production.

The problem with having too many eternal branches is that they quickly become unmergeable. The nice thing about feature branches is that it's the author's responsibility to make it mergeable. But if you having a bunch of eternal branches none of which are "owned" by one person, when it comes time to merge them and there's dozens of merge conflicts there's not one person that can set down and know what the correct fix is for all of them.

I think the idea is that the branches cascade. You would never create new commits directly into release or master, the flow would only ever be develop > release > master, thus making merge commits and conflicts impossible.

That doesn't work in practice, you are always going to need to "fast-track" a bug fix, skipping develop (which has code you don't want to deploy).

That's exactly what hotfixes are for. A completed hotfix will merge directly into develop and master simultaneously (practically speaking). This allows you to keep your unrelated develop commits out of the master until you're ready to merge it all.

This can become very problematic.

For example:

Team is working on feature A and feature B. Each feature is developed on its own branch.

Feature A is ready for testing/integration, it is merged into develop.

Feature B is ready, it is merged into develop.

Now here is the problem:

Feature B is ready for release, but feature A is not. It is now not possible to merge develop into master without including both features.

The solution I use is to have master and branches. That's it. Master represents currently-running production code. Branches contain everything else.

This also happens to be how Github work. This article explains how it works with various levels of deployment before production - http://githubengineering.com/deploying-branches-to-github-co...

I'm a bit confused, why are you merging things into develop if they're not ready?

If Feature B isn't ready, it should stay in its own branch until it is.

Develop is for code that the developers say is ready. You might have bugs, poor merge resolution, etc, but any fixes made should be quick and should pave the path toward code that can be merged into master. If the problems are major, revert develop.

Master, on the other hand, should always be stable and rock solid. You can then have production servers that always pull master automatically, and staging servers that always pull develop automatically.

I've worked on multiple teams this way it works out quite well.

In the above example, say Feature A gets the go-ahead from the business user/product owner/whatever, and Feature B doesn't. From the dev standpoint both are complete but there may be some business reason to hold up Feature B. The owner(s) of Feature A are likely not going to understand why anything to do with Feature B has to hold up their release.

In your scenario, Feature B should not have been promoted into the development branch until everyone agrees it's going to be shipped. If it got into development without everyone's approval, then that is a business process problem, not a CVS tool problem.

At my last job, we had a 'gorilla' that had to approve every commit, and it was his job to coordinate between the project managers and the developers as to what was allow to be promoted to prevent exactly the scenario you described. It also had the benefit of making developers describe each commit clearly so that the gorilla could understand the change, which made looking at the commit history some time later (months/years) quite a bit easier too.

In that scenario is everything in develop simply waiting to be pushed to master, with no additional testing/approval? At that point why not push directly from feature branches into master?

Because features are not always isolated, sometimes they change behaviour based on changes in other branches. Testing features in isolation is different from testing an entire release.

We follow a similar process where I work and it works really well.

Something being merged into development means that it is 100% complete and ready to be deployed to production at any time. This means all QA and acceptance testing had to happen before merging.

What you're describing doesn't make very much sense. There are only two cases here:

1) A feature that's in develop may sometimes need to wait for something (QA, business validation, a go-ahead, whatever) to go to master, or 2) A feature that's in develop can ALWAYS go to master at any time.

In the first case, you can have feature X blocking all other features because it's in the same branch as them, which is the problem the GP is describing. In the second case, the two branches are the same, so why not just merge into master directly?

It's always #2, but just because a feature has been approved for master, doesn't mean all the features approved for master are stable together.

A feature might be stable as a standalone, but in virtually every software suite, features interact with each other. That is what develop is for. It's where all the feature branches meet and where any instability created by everything coming together is resolved.

Master, on the other hand, is the product of that successful resolution after all the bug fixes.

I've found that that generally leads to problems, so I prefer to have the feature that is going to be merged last be responsible for fitting in with the rest. That way, as described earlier, I don't have to wait for features that can't be merged now to merge the ones that can.

How do you know which feature will be merged last? In the teams I've worked in previously, everything happened in parallel. You had no way of knowing what feature was going to be merged when. So, essentially, we completed a feature-branch, tested it, and merged it into develop. Then, at set intervals, we did some heavy testing on develop and fixed any outstanding bugs, before creating a release by merging to master.

Wrap Feature B in a feature toggle if its development ready but not business ready. Then when it is business ready, flip that toggle.

If part of the process is required approval by some customer/business exec, etc. . . don't merge it till it's approved.

If you need independent release cycle for Feature A / Feature B, you adjust GitFlow by basing all branches (feature/release/hotfix) from the master.

Let's say next release is Release-1.10

1. We merge Feature A and Feature B to it.

2. Feature A is tested and ready to be deployed. Feature B is not.

3. You either revert Feature B commit OR re-create the release branch with only Feature A.

4. Deploy the release branch.

5. Merge the release branch in to master.

This is exactly what we do at my current workplace where we have 4 developers working on changes with different release schedule.

And then do you need the 'develop' branch at all? If not, you're describing something similar to what OP is.

Yes, 'develop' branch is still useful. See my comment on that here: https://news.ycombinator.com/item?id=9744787

Does having a lower level of quality on develop hinder your ability to actually release code?

We have one particular repo at work that is just a pain in the ass to work with (Typescript analytics code that has to be backwards compatible to about forever), and we've pretty much abandoned the develop branch since releases got held up due to bugs in less important features that had been merged in without comprehensive testing. Pretty much everything now gets tested extensively on a feature branch and then gets merged directly into a release branch.

We might have swung a little too far in the other direction, I'm thinking we want to at least merge well tested bits back onto develop, but at least we can release the features that are actually done and cut those that are still having issues without having to do any major git surgery.

> We might have swung a little too far in the other direction

I think you're describing "GitHub flow", or how most people starting out with git would probably use it given no exposure to git-flow.

Github flow introduction: http://scottchacon.com/2011/08/31/github-flow.html

Documentation (it's really unnecessary if you get the idea): https://guides.github.com/introduction/flow/

This is how my team works. I always thought GitFlow was way too complex for our use case. The way you describe seems to work for us, mostly. There are still the occasional mistakes and commits to the wrong branch, often accidentally bypassing develop, which I guess supports the article's premise.

I don't agree with master being the production code. It's the default branch when you clone. I like to keep the production branch on a more explicit branch so my team knows they're dealing with release code.

I do something very similar; use master for dev builds that can be shared (since it's the default branch) and something like 'deploy' or 'deployprod' (which on second thought is a bit redundant) for release. Then, using a CI tool, you can have master go to a staging environment and deployprod go to production.

What would be an example where master differs from production?

Why not just use tags?

We use a master / development branch strategy. For us, the main problem with having one branch and tagging releases is that it's relatively common for work to continue on the development branch while the release branch is still being tested. For us, there's a 2 day period where we're testing out the upcoming release. Developers will be fixing bugs on this release branch, and also commiting new code for the subsequent release. If we had one branch with tags, developers would need to keep all their new code on feature branches until a release is completed, and the likelihood of accidentally releasing an untested feature gets a lot higher (one advantage of having two branches is that you can treat your production branch with a lot more care)

You might want to cherry pick some commits from the dev branch into a stable branch from time to time (security fixes, things like that).

Sure, you can do that with tags. Branch off from your tag, cherry-pick your commits, push and if tests pass create a new tag.

all code is release code