What is a pull request?

A pull request (PR) is a method to propose changes to a codebase. Software developers fork the main code repository (also called repo) into a separate branch, commit code to that branch as they work and create a pull request to flag their suggested changes for code review before pulling or merging the changes from the branch into the main codebase.

PRs are common mechanisms in Git repositories such as Bitbucket and GitHub. GitLab applies the term “merge request” instead of pull request for the same process.

Developers can create pull requests using the command line interface (CLI) or web interface. New pull requests are typically opened for bug fixes, dependency updates, new features or refactored code. Pull requests streamline code reviews, keep codebases up to standard and promote collaboration among members of software development teams.

PRs allow developers to craft source code and test it locally. Since code changes are isolated from the main branch, developers don’t need to worry about breaking the entire codebase.

The pull request methodology involves three vital roles that apply mostly to open-source projects but can also be adopted by proprietary or closed-source projects:

• Maintainers: Project maintainers manage (and often own) the project and have the authority to approve and merge PRs or reject them.

• Reviewers: These team members (who can be maintainers themselves or other active contributors with much experience in the project) review proposed changes for code quality and suggest improvements as they see fit.

• Contributors: These developers are tasked with making changes and opening pull requests.

Creating pull requests generally entails a seven-step procedure:

1. A contributor forks the main repository to create a new branch (using the git checkout command or the web interface) and clones this branch to their local machine.
   
   
2. The contributor works on their changes and commits code locally to the branch.
   
   
3. Once the contributor has finished and tested their code, they first pull the latest updates from the main repo to avoid any conflicting changes before pushing their code.
   
   
4. The contributor opens a new pull request for their proposed changes to be integrated into the main branch.
   
   
5. Reviewers receive notifications when pull requests are submitted. They check the PR to compare the differences (also referred to as diffs) between the contributor’s branch and the main branch, reviewing the code and commenting on areas that need optimization or improvement.
   
   
6. Contributors make additional commits based on the reviewer’s suggestions and change requests.
   
   
7. When all changes have been implemented, the reviewer notifies the maintainer, who approves the PR. The pull request is then merged into the main repository.

Software development teams can choose from a number of PR workflow options depending on their needs. Common pull request workflows include:

• Feature branch workflow

• Forking workflow

• git-flow

• Stacked workflow

Each new feature gets its own dedicated branch with a descriptive name to highlight the feature’s purpose. Once the feature is complete, developers can push the feature branch into the main branch and create a pull request.

This workflow maintains the stability of the main branch as contributors work separately on features. But managing multiple feature branches might become unwieldy.

The seven-step procedure outlined in the previous section on creating pull requests corresponds to a forking workflow. Open-source projects often employ this workflow, which also complements continuous integration/continuous delivery (CI/CD) practices. GitHub flow follows a process similar to the forking workflow.

Software engineer Vincent Driessen formulated git-flow in 2010. It’s typically used for building software with rigorous release schedules or those supporting various versions.

This workflow follows a branching model composed of these branches:

• main holds the latest stable release

• develop acts as an integration branch for bug fixes, features and other code changes included in the next release

• feature uses develop as its source branch and target branch, with features merged into develop when they’re ready

• release is forked from develop and tagged with the version number for the next release, then merged into both develop and main once it’s fit to ship

• hotfix is forked directly from main to fix any high-priority or high-severity production issues, then merged into both develop and main as soon as fixes are done

Developers create pull requests for hotfix , feature and release branches that need review.

A stacked workflow breaks down large tasks into a sequence of small, incremental code changes. The next code change is dependent on the previous one, so pull requests are built on top of each other.

Consider a feature that involves changes to these functions: the database or data model, API and front end. In the conventional feature branch or forking workflow, a contributor must wait for the PR for the database or data model changes to be reviewed, approved and merged into the main branch before they can start on the API updates. In a stacked workflow, this waiting period is eliminated—the contributor can branch off from the database or data model changes to begin work on the API, submit a PR for that and branch off the API changes to tackle front end tasks.

Pull requests offer these advantages:

• Cultivates collaboration

• Enhances code quality

• Increases transparency

• Strengthens coding skills

Pull requests foster cooperation, encouraging team members to work together regardless of their role. PRs facilitate feedback and how to deal with it, ignite discussions and spark ideas for refinements.

PRs kick off the code review process, helping pinpoint bugs, deviations from coding style and standards, performance issues and security vulnerabilities. This additional oversight maintains or even improves the quality of code.

Pull requests allow teams to see what changes were implemented, who made them, where they were applied and the reasons behind them. Such visibility provides better insight into the state of the codebase and the project itself.

Both reviewers and contributors can learn from each other, picking up new techniques along the way and discovering novel approaches to problems. Beginners and new team members can also study previous PRs to better understand the codebase and get up to speed on the team’s coding standards and best practices.

While creating pull requests seems straightforward, here are some tips and tricks that can further smooth out the process:

• Consider drafts

• Details matter

• Maintain focus

• Stay current

• Take up templates

Draft pull requests or merge requests serve as an avenue for developers to share their work in progress. This allows team members to begin collaborations earlier and invites feedback sooner so those who are stuck on a problem can crowdsource potential solutions from their teammates.

Developers must provide clear, concise and specific messages for their new commits. Clarity, conciseness and specificity also apply to PR titles and descriptions, making it easier and quicker for reviewers to glean the intent behind code changes.

Bundling multiple issues into a single PR can result in longer review times and more revisions. Each pull request must address only one bug fix or feature. Focused pull requests can lead to more efficient code reviews.

Before pushing code and opening a PR, developers must make sure their branch is up-to-date. Picking up the latest changes and any new commits prevents conflicts once the pull request is merged. They can use either the git pull command to fetch and merge changes from the target branch or the git rebase command for a clean git commit history.

PR description templates help ensure consistency and provide vital context to streamline code reviews. Teams can craft a template for different pull request types, such as bug fixes, features or refactored code.

Templates are usually written using the Markdown markup language and placed in the root folder or main branch of the project repo. Typical fields include:

• Problem or feature description (with a link to the corresponding ticket in Jira or other issue tracking software for reference)

• Solution outlining code changes in detail

• Testing, such as unit test or integration test cases, test coverage and steps to manually validate the solution if applicable

• Configuration changes

• Checklist of relevant tasks, such as code documentation and clean code builds without errors or warnings

Automating PRs can speed up the lifecycle of a pull request from creation through review and merging. PR automation encompasses a layer of systems that help ease bottlenecks:

• Stacked PRs

• CI/CD pipelines

• SDLC management systems

• AI-powered coding assistants

Most Git repositories aren’t designed to support a stacked workflow, but some tools abstract away the complexity of syncing stacked pull requests and handling merge conflicts. These tools include the Graphite platform, which has a CLI and an extension for Microsoft’s VS Code for stacked PRs and a web interface for managing them; Meta’s Sapling source code management system; and the open-source ghstack CLI for submitting stacked diffs to GitHub as separate pull requests.

As an automated DevOps workflow, the CI/CD pipeline helps ensure code quality. Platforms like GitHub Actions and GitLab and other CI tools can run unit tests and integration tests and deploy preview environments that act as sandboxes for viewing and testing code changes in PRs.

CI/CD pipelines also reinforce secure coding practices. Static code analyzers and other static application security testing (SAST) tools integrate seamlessly with most CI/CD environments to pinpoint likely code vulnerabilities. DevOps teams can implement pre-commit hooks for secrets detection, making secret scanning a required step before developers commit code or initiate pull requests and blocking changes that contain hardcoded secrets.

Platforms like Jira and IBM® Engineering Lifecycle Management (ELM) support the tracking and management of pull requests throughout the software development lifecycle (SDLC).

As part of the ELM suite, IBM Engineering Workflow Management (EWM) and IBM Engineering Integration Hub embed PR automation directly into development workflows. EWM can connect with Git repositories through the Hub’s connectors and trigger PR creation from work items. When a requirement or change request is approved in EWM, a rule can automatically open a pull request in the linked Git repository and prepopulate the description.

Al-driven automations in ELM can also run static analysis and test suites once the PR is opened, posting results back to the work item and blocking merge until criteria are met. Meanwhile, the Hub synchronizes the PR status across tools, reflecting it in the repository and EWM dashboards for real-time visibility.

AI-powered coding assistants like GitHub Copilot and IBM Bob can augment pull request workflows. For instance, Bob can generate well-formatted, meaningful commit messages. It examines the branch name and commit history to match a project’s style conventions.

Bob can also create a pull request directly from a developer’s IDE. It analyzes the branch name, code changes and commit history to understand purpose and scope. It then generates a PR title and detailed description that summarizes the changes, automatically detecting and using a project’s existing PR templates for pull request descriptions.