Our team seems to be running into this problem over and over again. When we start on a project we create an integration branch from the master and call it stable. Now, each individual developer branches out from stable and once they are done, they create a pull request to the stable and do a squash and merge before closing it.
The problem happens when we want to merge stable back to master. We usually rebase on top of master but this leads to many conflicts since 2 months down the line master has a lot more commits than when we branched from.
I read some posts like - Git Workflows: Rebasing Published/Shared Branches and some of them seem to advocate merging master to stable from time to time before doing the final rebase of stable on top of master at the time of creating a pull request and then there was one What is the right git workflow with shared feature branches? which said that back merge from master to stable is a bad idea.
My question is - Is merging master to stable from time-to-time the ideal solution here to prevent the rebase conflict hell which we go through every time or are there any better solutions out there? If this was already answered please let me know.
We can't merge stable to master sooner because master requires the latest and greatest end-to-end functional production ready code.
Is merging master to stable from time-to-time the ideal solution here to prevent the rebase conflict hell which we go through every time or are there any better solutions out there?
In your particular workflow, where master is actively modified while stable is updated... yes, even though it is not a best practice.
Ideally, master should not evolve much while your integration branch (stable) is updated.
An example of such workflow: gitworkflow, which uses a "next" branch as integration, but will then remerge the feature branch themselves directly to master (which has not change much since the last release)