Pull-What-Now?
Since their initial appearance on GitHub, pull requests have become increasingly popular with developers as a means to both further optimize workflows, and to facilitate communication between the leaders of a project and its contributors. Though at first glance confusing to unfamiliar inductees (myself included), Git-savy-gurus have praised pull requests for making code review simpler, faster, and more thorough (among many other things). Intrigued? You should be.
A Better Mousetrap
A pull request is, in a nutshell, a way to look in detail at code contributions, review them, discuss them, and then instantly incorporate them into your existing code base (or not). In other words, “Here’s my commits, and here’s why you want them,” or “Please sir, I’d like some merge.”
While similar in nature to a pre-commit review (or “hook”) in centralized version control, pull requests offer two tremendous advantages: they can (and should) be created before a single line of code has been written, and once it has, that code is already available for peer-review. Think project tracking in Jiraor Trac, but with code commits automatically attached, and accessible by developers in a more intuitive context. Simple as that.
For project leaders, this means the ability to provide contributors with issue-specific guidance and oversight throughout the development process, instead of just at completion. For developers, this means useful feedback, a clearer understanding of requirements, and avoiding the ever-frustrating “Sorry, those all-night coding sessions were in vain" moment.
Win-freaking-win.
So: what does this imply for teams, open-source and Enterprise alike?
Improved Collaboration Within De-Centralized Groups
While distance is a given in open-source, community teams, Enterprise development is also increasingly distributed. By providing constant progress updates and an outlet for their discussion, pull requests help promote communication and cohesion between developers, regardless of proximity. So, the server guys on the east coast are always up-to-date with the client engineers on the west coast, as are the overseas web and graphic designers. Booyah.
Intelligent Distribution of Code Review Process
Forgoing review until code completion means two things: more time spent understanding the nature of what’s being submitted, and less time spent evaluating its implications. Using pull requests, review becomes an ongoing component throughout the development the cycle, accessible by all relevant parties. This means more “eyes on the ball” to catch illusive issues, and also increased development agility as feedback and discussion help guide development. Oh, and not being forced to review a 12-commit submission all at once is nice too.
Less Redundant Work
Duplication of development effort isn’t just wasteful; it’s also incredibly frustrating for developers and project leaders alike. No one appreciates having his or her hard work turn out to be unusable. Whether it’s two engineers slogging through the same lines of code unnecessarily, or a feature implementation that fails to meet its intended requirements, these setbacks cost time, money, and most importantly moral. By keeping everyone involved up-to-date and on the same page, pull requests make for a smoother release.
A Better End Result
What do improved communication, code review, and workflow have in common? A better product. Delivered quicker, and at a lower cost. While pull requests are no magic bullet for fixing an out-of-whack development cycle, they further capitalize on the greatest success of distributed version control: cooperative coding. The more a team can support each other and work in unison, the more likely they are to produce an outstanding end-result, and pull requests are an excellent to tool for achieving this. Just remember to practice proper etiquette.
