Is that the most meaningful question?
Debate on the Pull Request (PR1) process is endless. Despite all the arguments against it I’m for PRs. Reflecting on this position brought me to the Ship / Show / Ask adaptation of the process. It offers an easily communicated middle-ground between traditional PRs & mainline CI. Yet, coming to this middle-ground highlighted how most branching strategy debate is more about human practice than technical guard rails.
For many years PRs have been the only process I’ve worked with for team development work. A recent internal project initially followed that same trend. This served us well in terms of sharing knowledge as the project rapidly evolved without introducing delays. However, the development of the projects core functionality fell to an engineer who drove a merge to mainline approach instead.
I found this challenging for a variety of reasons. Not least because it flew in the face of what I had become so accustomed to being the ‘right’ way. I urgently looked for a counter argument. During that process I found several things:
As a declared PR advocate this offers a more nuanced approach than I’d previously held. It requires no new technology to implement, enacted through repository merge configuration tweaks only (GitHub, GitLab, BitBucket for example). It’s easy to communicate. It retains the routine checks & balances of PRs, personally I’d only ever see the ‘ship’ option being used for small hotfixes. It offers more latitute, and more rapid throughput, among experienced and trusted engineers.
Yet, regardless of the branching strategy well honed collaboration practice is fundamental to successful progress. In my opinion the most important aspects of that practice include small merge diffs, automated code linting, professional reviews (prompt, respectful, thorough, and practical), and monitoring via source control metrics. Further to this, varied forms of communication (advance planning, retrospective session, product focused, technically oriented, formal, informal, etc.) are good for team health. Ideally encouraged or scheduled if needs be, without straining delivery commitments of course.
Pull Request (PR): A notification given by developers when they are done building a feature. ↩