What is a Pull Request?

A pull request – also referred to as a merge request – is an event that takes place in software development when a contributor/developer is ready to begin the process of merging new code changes with the main project repository.

A project’s repository (or “repo”) is where all the project code, product knowledge, metadata, and much more data/information is stored. A repository maintainer/manager is someone on a DevOps or operations team who is responsible for maintaining said repository. They are in charge of which updates can be merged with the final project and ultimately made available to end users.

During a pull request, the repository maintainer reviews new code updates from a developer to determine whether or not it is ready to be released. Without pull requests, unfinished or incorrectly written code updates could be prematurely merged with the main repository and break or cause issues with the live product. Pull requests ensure the integrity and user experience of the product by only merging code that has been appropriately reviewed and approved.

In addition to protecting the main project repository, pull requests also encourage collaboration and open communication when working on new product updates. They also help to keep teams motivated by highlighting and notifying the team when someone completes a new feature.

How do Pull Requests Work?

A pull request works by allowing developers to create new features or squash bugs without affecting the main project code or what the users are seeing. This way, they are able to write and test code changes locally without having to worry about breaking the overall product.

Pull requests follow a basic five step process:

• Fork Main Repository and Create a Local Clone. First, the developer creates a fork of the main repository, and then clones this onto their local machine.
• Make Needed Changes Locally. The developer then is able to make their needed changes or additions to the code whether they are working on resolving an issue or new feature.
• Push Local Changes to Forked Repository. Once the developer has completed and tested the new code changes, they push these changes back to the forked repository they created in step one.
• Make a Pull Request. This is where the actual pull request takes place! After requesting a pull request, the main repository maintainer is alerted for review. The maintainer will then review the work done in the developer’s forked repository, and then make any comments or request any edits that need to be made for approval.
• Any edits are then sent back to the developer for additional commits (changes to code) that may be needed.
• If no edits are needed, the pull request is approved by the maintainer.
• Merge with Main Project. Once the repository maintainer has approved a pull request, the developer’s new updates in the forked repository are merged with the main project repository. The product is then updated with the new feature or bug fix, and can now be viewed by end users.

In some cases, a developer may also make a pull request for a feature or update that is not yet completed. This way, if a developer is stuck on a new update they’ve been working on, they can now get feedback from other team members and work through possible solutions.

In either case, using pull requests ensures that any new update for a given project has been thoroughly reviewed and approved before it is merged with the main repository. This helps to prevent future issues and ensures a seamless user experience with minimal downtime.

Creating a Pull Request

Creating pull requests may vary from organization to organization based on the tools being used and the type of repository (ex: GitHub, BitBucket, etc.). However, creating a pull request often involves these same three elements:

Drafting

When creating a pull request, the developer will first begin with a draft. Here, they will be able to title and briefly describe their code changes. They will need to include information about the type of update (whether it’s a new feature or a bug fix) as well as its source repository/branch and destination repository/branch.

A draft pull request cannot be merged until the developer has marked it as ready for review.

Merging

Merging occurs once a developer’s submitted pull request has been approved by the repository maintainer. Before merging, the repository maintainer will need to review the developer’s completed work. They will comment on any issues, and request edits from the developer as needed. Once any and all updates have been made, the repository maintainer can then safely merge the updates with the main project repository, making it live for end users.

Updating

If the repository maintainer requires any changes to the code updates before merging, the developer will be alerted and provided with any comments or feedback for fixing the issue. Once the developer has resolved the issue, they can update the pull request with their new commits added for further review and approval.

Pull Request Templates

Pull request templates can be created and stored to help expedite the process and ensure consistency across all team members. When creating your pull request template, it’s important to include:

• Summary of Code Update: Was this a bug fix or a new feature? Summarize what was accomplished with this new code update.
• Unit Test Cases: Was this code update tested across all devices and browsers?

The specifics of your pull request template will vary based on the repository your organization uses. Different tools have different capabilities and options to make pull requests a breeze for your team.

An Example of a Pull Request

Now that we’ve gone through what a pull request is and how they work, let’s take a look at a possible pull request in action.

1. Russell is a developer at a software company that has a mobile application that lets users rate and review different wines.
2. Russell needs to create a new feature that allows the user to highlight their “Five Favorite Wines”
3. To begin working on this new feature, Russell first creates a fork of the main repository and clones this to his local machine.
4. Russell then develops this new feature locally.
5. Once completed, Russell can push his code updates to the forked repository he created.
6. Now Russell can create a pull request!
7. Once the pull request has been submitted, Erica (the Repository Maintainer) is alerted to begin reviewing Russell’s new code update.
8. Erica can then request any follow-up commits from Russell as needed.
9. When any and all change requests are made, Erica will then approve Russell’s pull request.
10. Russell’s new update is then merged with the main project repository, and application users can now begin using the new application feature.

To learn more about how PagerDuty can help augment your software development lifecycle, give us a call and start a 14-day free trial—no credit card required.