My git flow is similar to the github flow- ephemeral feature branches that merge to and from
master after code review and QA.
However there is one important difference- in order to QA, developers merge to
staging. In most cases this merging happens in the CI- merge conflicts are rare.
There are (atleast) 3 issues:
- In some cases, some PRs make it to
stagingbut not to
master(PRs get rejected). For now, developers deal with it by manually re-setting
masterwe do a “squash and merge” while in
stagingits the standard merge. No specific issue because of this right now but seems like it might break in the future.
- Merge conflicts have to resolved twice- once when deploying to staging, and another time when merging to master.
Is there a way to achieve to have branches to have code deployed to
staging but not to
master and keep
master somewhat in sync without manual intervention.
One idea that comes to mind:
The CI keeps track of which branches are in staging (but not in master)- say all open PRs that a developer has marked “ready for staging”. On every staging deploy, the
staging branch is reset to
master and these branches are merged. But I’m not sure how a CI would save this kind of “state”. Not to mention, this seems like a very complex flow.
Go to Source