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.