As the Web Flow features gained traction, we began exploring entirely new functionality to expressly encourage people into collaborative workflows early in their process, at times where review and feedback might otherwise be missed. One of the more prominent examples was Quick Pull-requests.

Note: Read the related announcement post on the GitHub blog.

One reason getting started with GitHub and the entire concept of "Pull Requests" is hard is that people often don’t even think to create a new branch before making a change, let alone about creating a PR for the change.

The natural behaviour is simply to go to the file you want to change, click "edit", and commit the change straight to the main branch. The problem with this is that it skips a critical opportunity (and benefit!) of the open collaboration model—bringing visibility to changes and enabling for others to provide feedback.

Rather than just making a change directly on the main branch, we wanted to find a way to change the default path without getting in people’s way. Now, whenever someone goes to make a change to a repository using the browser, the new Quick Pull-requests workflow provides the option to make the commit on a new branch and open a PR—there and then, creating a new default without adding any friction to the process.

By introducing the new default after the edit has already been made (but before the commit) it saves people from having to remember to create a branch first, and redirecting them to open a Pull Request asking for feedback on their suggested change, even small changes can become valuable discussions and opportunities to improve software quality.

Crucially, people are still free to merge the pull-request immediately if that makes sense, but the good thing about having a PR for every change is it creates a place for discussion to happen in an asynchronous way—even if the PR has been merged. And if that really isn’t what someone wants, it’s just a simple choice to just commit to the original branch without a PR too. No harm, no foul.

We also introduced a ton of other related improvements, such as enabling edits of files within an existing pull-request, which also make it easier for multiple people to collaborate on tweaks and improvements without everyone involved having to have a local clone of the git repo and all the associated.

It’s changes like this that I've ended up being most proud of when considering my 5 years of contributions to the GitHub codebase. Simple changes and interactions with a relatively small surface-area, but which have a truly monumental impact (especially over time!) in helping everyone using the product bias towards open and asynchronous-friendly collaboration patterns as the default—whether internally within teams and companies, or in the open-source community.

It’s also worth noting that a lot of these small details and unglamorous interactions within the products we build often feel obvious and trivial in retrospect—but that’s actually an indication of how important (and difficult!) work that matters often is to do. The hardest part of product design is being able to think forwards enough to see what will become obvious in retrospect with the passage of time.