You Might Be Better Off Without Pull Requests - Ham Vocke

Pull requests and mandatory code reviews have become popular tools for modern software development teams. A tried-and-trusted alternative to pull requests that seems to have fallen out of style is Continuous Integration (CI) and merging to main directly. How did we get there? What are possible benefits of using CI over pull requests? Are these two approaches mutually exclusive? And how could you get started with CI and avoid pull requests moving forward if you wanted to? We’ll explore all of these questions in this blog post. Have fun!

In the past 15 years the way teams collaborate on a shared code base has changed. Thanks to the increasing popularity of distributed version control systems like git and the rise of code forges like GitHub, GitLab and others, collaborating on a shared code base has become more convenient than ever before. A small inventioned called “pull requests”1 lowered the barrier for open source collaboration significantly. They made it easier and more compelling for strangers on the internet to contribute to open source code bases by forking the original repository, making changes like fixing a bug or adding a new feature, and contribute their changes back to the original code repository. Pull requests allow maintainers of code repositories to take their time to review incoming code, leave comments, ask for changes, and ultimately accept or reject a pull request.

What worked incredibly well for open source software projects quickly grew in popularity outside of open source development, too. Teams collaborating on software within companies quickly adopted this pull request-driven workflow and it’s become a seemingly standard practice for software development teams across the globe.

A pull request or something, don’t ask me how this works.

Honestly, pull requests sound like a pretty sweet tool for collaborating on a shared code base. They are a huge success in the open source space, and looking at that success alone it’s not surprising that a lot of teams use a pull request-based process for themselves. On the other hand, there are a lot of voices out there highlighting how using pull requests as the default mechanism for collaboration can slow down your team and prevent you from getting changes into the hands of your users quickly and reliably. Patterns that worked well for low-trust open source communities, they say, didn’t translate well to teams where you know and trust all of your collaborators. Critics of pull requests often suggest alternative workflows that predate pull requests and even git and other distributed version control systems.

To better understand what they’re talking about, let’s understand how we got here, why exactly pull requests can be problematic, and what good alternatives might look like.

Software Development In a World Before git

Time for an unpleasant truth (it’s unpleasant because it makes me feel old): git, a version control system that eventually grew to become the de-facto standard in today’s world of software development, was released back in 2005. It’s likely that a solid bunch of you folks out there who are now in the software development industry haven’t used any version control system other than git. That’s perfectly fine, you dodged a couple of bullets and missed out on a lot of weird stuff we had to put up with before. To understand how we got to the point we’re at today, let’s first understand how we used to develop software before git (and other distributed version control systems) were a thing.

Before git became popular, software development teams had a few popular options to version control their code. They would either…

use Subversion (svn)

be stuck on CVS (cvs), a predecessor of Subversion

use something proprietary like Visual Source Safe and hate coming into work every damn day

or — and you’d be shocked to learn how often this happened long until version control systems were a thing — use no version control system at all. Maybe, if you were lucky, there was a shared file system, but that’s about it.

CVS is free, open source, and fairly rudimentary — but it worked well for a lot of teams. Subversion, its successor, also free and open source, took a lot of ideas from CVS and improved on them. Both version control systems (VCS) had a slightly different, dare I say simpler, workflow compared to the distributed version control systems (DVCS) we know today (like git, mercurial, or bazaar if you still remember those). In a regular VCS, your typical workflow would look somewhat like this:

You check out a local working copy of a code repository

You make a change to the code on your local machine

You do a commit (e.g. svn commit) to send changes from your local working copy directly to the central code repository and share it with everyone

You read that right. A commit would immediately send your code to the central repository, and other developers could pull it with an update...