Looking for a Git branching methodology to allow 2 staging environments

Question

We've been happily using this branching methodology for years https://nvie.com/posts/a-successful-git-branching-model/ whereby we have our master branch auto deploying to our production environment, and our develop branch auto deploying to our staging environment. We take feature branches from develop, work locally and then merge to develop when ready for testing on staging. When we're happy with all new features on staging, we take a release from the develop branch and merge into master which takes all new features from staging to production.

Recently we've had instances where a bunch of features get "blocked" on staging because there is also a bigger unfinished task on the develop branch.

We use heroku so we know one solution is to use feature apps which build from the feature branches and then only merge to staging when ready to go to production, but for our setup its not so easy to do this so we had the idea of creating essentially a 2nd staging environment.

We'd have a "stable" branch and environment and then a "develop" branch and environment. Feature branches would get taken from stable, worked on locally and then merged into develop for testing. Once the feature is ready it can be merged to stable and then when we're ready to release to production we take a release from stable to master. Master > stable > develop.

This seemed like a good plan until we put it into practice and started getting strange merge conflicts when trying to merge feature branches taken from stable into develop.

The example merge conflict has happened because some code has been merged into develop since the feature branch was taken from stable. So the code isn't in the feature branch but is in develop. I would have expected git to be able to merge this and know that the code added to develop should remain.

What are we doing wrong here? Are we just trying to do something thats not possible. Any other suggestions of a branching methodology that solves our issue of not blocking staging from going live, without needing lots of feature branch apps?

Answer 1

The example merge conflict has happened because some code has been merged into develop since the feature branch was taken from stable.

That is why, ideally, you rebase the feature branch on top of origin/develop locally, resolve any conflict there, then force push and merge to develop (the merge will be a trivial fast-forward one)

This assumes you are alone working on a feature branch, or that you have a good communication to alert your collaborator they will need to reset their own feature branch to the one you just force push.