I am currently working on a large project involving at least 3 teams working on separate feature sets in the same codebase versioned on Git. Some features require back-end integration and stabilization and I've heard of features taking months from being ready to going live.
I've seen A successful Git branching model and found it unsuitable for this situation, especially because feature branches must derive only from the development branch.
I assume features should always be in sync with master which represents current production code. The process of taking code from master->release->develop->feature makes keeping features up-to-date more difficult.
Plus, when complex merge conflicts arise on a merge from release to develop, who should solve it? On a large project with distributed teams with non-overlapping responsibilities not a single person is best suited to resolve complex merge conflicts across a whole codebase. No one owns the develop branch, neither a person or a team.
Merging features to and from the development branch also brings to them not-yet-production-ready code from other features while trying to keep them up-to-date with master, making feature branches sort of infect one another in the process. Once I've pulled from development to update my feature with latest production code and be able to call it "finished", I've infected my branch with supposedly finished code from other features that have merged to development. If any features in development are found to be either hard to stabilize or de facto a bad idea, we've compromised the development branch and all its feature branches.
Instead of deriving from the development branch, I found deriving from master and merging into disposable "release-package" branches lead to less headaches.
When merge conflicts arise in master->feature merge, the person doing the merge is the one most suited to resolve them. She knows the code and what it should do, it's her feature.
Features are streamlined into disposable release branches that can be deleted and reformed at any time. If a feature is not ready to go live by the release deadline, we can delete and recreate the package without it.
Development is only done in feature branches. Release branches only receive merges. If features conflict in a meaningful way, we should question if they should be merged into one another or scheduled for sequential release, one after another. In the case we merge two features into one another, the scenario might look too similar to NVIE's branch model, but here we are given a choice to do it or reschedule the features and recreate the release package.
The disposable nature of release branches and the independence of feature branches makes it possible to stage fallback releases.
If all four features don't stabilize until the deadline, only 1 and 2 go live.
Is my proposal a suitable branch model?
PS: I've read this answer about branch models vs quality and CI, and I don't think it applies. This project does have a quality problem. This quality problem will be there tomorrow and the next month, and while this quality problem remains there must be a suitable branch model we can use, one that does not make life harder.