Task Branches & Merge Trains
Big feature, multiple people, different stacks? Don’t cram it all into one feature branch. Split the work into short‑lived task/ branches, review them in isolation, then assemble them into the parent feature/ branch. If you use GitLab Ultimate, use merge trains to line up the merges reliably.
Why split into task branches
- Focused reviews: smaller, cohesive diffs per concern.
- Parallel work: frontend and backend can move independently.
- Cleaner integration point: the feature branch becomes the rendezvous for assembly and testing.
Example flow
This way you only need a shorter, easier final code review on the pull request to main to make sure integration/rebase went fine (happy devs). You merge a complete feature into main with everything needed to test it end‑to‑end (happy QA). It’s releasable (happy PO).
→
squash merge
GitLab merge trains (optional)
- Don’t let this become the new
develop: the feature branch should still merge the smallest yet complete feature, just one, not many. - Coordinate your task branch merges and complete the pull requests just before you merge the feature branch: it’s easier to handle conflicts separately rather than rebase all combined code at once.
- If you use GitLab Ultimate, make the pull request for
feature/GG-1tomaindepend on the relevanttaskbranches, then start a merge train that includes all relatedtaskandfeaturebranches. Your pull requests will be merged together in a safe order.