I wrote this article for the Learnosity blog, where it originally appeared. I repost it here, with permission, for archival.
A few weeks ago, a debate started on our channel for Git-related discussions. Following someone posting a link to Nicola Paolucci’s article on Core [Git] Concept, Workflows And Tips, a question was raised:
Do we really need merge commits?
What sounded like a fairly straightforward question quickly snowballed into one of those long chat threads that left us none the wiser. A follow-up face-to-face discussion helped us get down to the root of the problem: code and functional reviews on feature branches may leave us exposed to integration issues after non-fast-forward merges, and can only be caught too late for comfort.
We had to consider our Git workflow alongside the lifecycle of our tickets to come up with an improvement. Merge commits remain, but we rebase (and fix conflicts) on the latest main branch before any review in order to make sure we look at the final code.
The rest of this article describes our Git workflow, our ticket lifecycle, their interactions, and how we made them better.
tl;dr
- Rebase onto
developbefore code review (original developer) - Rebase onto
developbefore functional review (functional reviewer) - Deploy to staging as soon as possible (i.e., all codebases merged for the feature; original developer)