Working on T395426: 🧬 Sync queryservice-ui with upstream, T399300: Query Service examples not loading on Cloud instances, and T358602: Remove Query Builder notice in Query Service highlighted difficulties in our current git branching strategy of merging upstream/main into origin/main.
- When resolving conflicts you're having to compare the new upstream state, with our dirty state that's a mix of old upstream commits and WBaaS modifications. The new changes coming in aren't something the team has been involved with the development of, so it can be difficult to know how best to resolve these conflicts.
- There is the potential for there to be a lot of changes coming in from upstream to understand (due to not doing updates very often).
- The WBaaS modification patches are spread throughout the git history, and with each upstream sync our commits get pushed further down in the history, making it harder to keep track of the modification we need to maintain and apply.
Rebasing our WBaaS changes on top of upstream/main would have the following benefits:
- Our WBaaS modifications are kept all together at the tip of the git history.
- There is likely to be less WBaaS modifications than upstream changes.
- Any conflicts that occur should be easier to resolve as we are comparing our modifications, which we developed and so have a better understanding of, with a clean upstream state.
In order to avoid having to rewrite the history of the main branch with each upstream sync, the new branching strategy has been suggested:
- We create an origin/upstream branch which tracks upstream/main which we don't push any modifications to, it only pulls changes in from upstream.
- We create an origin/develop branch that holds all our wbstack modifications, which is periodically rebased on top of origin/ustream.
- PRs to be reviewed are opened against the origin/develop branch.
- When we want to do a release, we tag the tip of the origin/develop branch with the version number (we could also make a release/x.y branch as well before tagging, but I don't think the origin/develop branch will be active enough for that to be necessary).
The following diagram helps describe the new git branching strategy:
We will try this out on the queryservice-ui repo first. If we like it, there is the option to roll it out to other similar repositories that suffer the same difficulties.
A/C:
- New branches are created in GitHub
- GitHub Actions are updated to use the new branching strategy
- The README is updated to document these changes