Understanding Pull Requests: Concepts and Typical Workflow

g4e stands for Git for Enterprise Developer; this series uses the g4e tag for easy reference and search.

Pull requests are a unique Git workflow that help teams control code quality, automate builds and deployments, and foster better collaboration.

What is a Pull Request

A pull request (PR) is a request to pull changes from one repository or branch into another. It originated on GitHub to enable code exchange between different repos. Developers fork a repository, make changes, and then submit a PR to the original repo owner for review and merging.

In enterprise development, branches are typically used instead of forks, making PRs a bridge between branches within the same repository.

Typical Pull Request Workflow

The typical PR process consists of four steps.

1. Create a Branch

Usually a feature branch is created from the master (or main) branch for a specific production release. In the illustration, a feature branch is created from commit c4 to develop new features or fix bugs.

2. Create a Pull Request

After at least one commit on the feature branch, a PR can be created, specifying the target branch (e.g., master). The PR name reflects the intention to pull the changes into the target branch. A PR cannot be created if there are no changes.

The PR establishes a request‑to‑accept workflow, separating code modification from code acceptance, enabling code review, static analysis, testing, and clear permission boundaries.

PRs always compare against the latest state of the target branch, tracking differences as both branches evolve.

Two ways to create a PR:

Method 1: TFS/VSTS prompts the user to create a PR when code changes are detected on a branch.

Method 2: Directly create a PR from the PR web page.

A PR includes the following key information:

Source and target branches : The source branch contains the changes; the target branch will receive them.

Title and description : Detailed explanation of what the feature branch will modify.

Reviewers : People who will review the code and receive notification emails.

Work items : Associated tasks or requirements linked to the changes.

Files and commits : List of modified files and commits.

Once created, team members can discuss and track changes via the overview view.

3. Update the Pull Request

After creation, the PR continuously tracks changes on both branches. Developers can push new commits, and the PR UI updates instantly.

Reviewers can view any specific change or the cumulative diff, which is crucial for effective code review.

4. Complete the Pull Request

When the feature branch changes are deemed complete, reviewers approve the PR, and the team clicks the “Complete” button.

All reviewers should provide feedback before completing. The system does not restrict who can click “Complete” as long as conditions are met, encouraging collaborative quality control.

After completion, TFS/VSTS merges the feature branch into master. Users may choose to delete the feature branch or perform a squash merge, which condenses all commits into a single one for a cleaner history.

The PR status updates to indicate completion, and the master branch history shows a new commit linking the PR and its associated work items.

Summary

Pull requests are a distinctive Git feature that unlocks the full power of Git for collaborative development, code review, and quality control. This article covered the PR workflow, highlighting how reviewers, branch mapping, and CI integration can create a seamless, automated quality gate. Further chapters will explore deeper integrations with Visual Studio, command‑line tools, and advanced scenarios.

Related articles:

DevOps Documentation Center Technical Practice Evolution

Microsoft R&D Cloud Suite VSTS in China

Markdown/reST Documentation DevOps Pipeline

7 Useful Git GUI Clients

Using SSH to Connect to TFS/VSTS Git Repositories

GitHub + VSTS Bidirectional Sync