Pull Request: What It Is, the Creation Process and Code Review

What is a Pull Request?

Pull Request (PR) is a formal request to include changes from one branch into another within a distributed version control system. PR is a central element of collaborative development on GitHub, GitLab, and Bitbucket platforms, combining code discussion, automated testing, and the change approval process.

The name “Pull Request” reflects the essence of the operation: a developer asks (request) the repository owner to “pull” their changes. The term was introduced by GitHub in 2008 — before that, a similar mechanism existed in the form of patches and merge requests (GitLab’s term). Today, PR is the de facto standard for team Git development.

According to GitHub Octoverse, 2025, 89% of open-source projects require creating a PR for making changes. In corporate development, this figure reaches 95%. PR has become not just a technical tool but a part of development culture: through PRs, knowledge transfer, bug detection, and architectural decision alignment take place.

Pull Request Components

A typical PR consists of a title, description, list of changed files (diff), reviewer comments, and CI check statuses. Each PR is linked to a specific source branch and target branch, and after merging it can be automatically deleted.

How to Create a Pull Request

Creating a PR begins with publishing a feature branch to the remote repository. After pushing, the developer opens a PR through the platform interface or via CLI (gh, glab). Let’s look at the process using GitHub as an example.

Pushing a Branch and Opening a PR

The first step is to push the feature branch to the remote repository and create a Pull Request through the web interface or command line.

# Create and push a feature branch
git checkout -b feature/biometric-auth
git add src/auth/
git commit -m "feat: add biometric authentication"
git push -u origin feature/biometric-auth

# Create a PR via GitHub CLI
gh pr create --title "feat: add biometric authentication" \
  --body "Implements fingerprint and face recognition login.
  Closes #142" \
  --base develop

After creating a PR, GitHub automatically runs CI pipelines (GitHub Actions), checks for conflicts with the target branch, and invites reviewers. The PR description template can be configured via .github/PULL_REQUEST_TEMPLATE.md so that all PRs contain required sections: goal, changes, testing, related tasks.

Description and Tagging

A quality PR description includes: a link to the task (issue/ticket), a brief description of changes, testing instructions, and a list of related changes. Labels (bug, feature, refactoring) help categorize the PR, while assignees and reviewers are assigned automatically via CODEOWNERS.

# Assign reviewers via CODEOWNERS (file in repo root)
# Example .github/CODEOWNERS:
# src/auth/ @team-auth @senior-dev
# src/api/ @team-backend
# *.kt @kotlin-team

# Create a PR assigning reviewers via gh cli
gh pr create --reviewer "team-auth" --label "feature"

CODEOWNERS is a standard GitHub/GitLab mechanism for automatically assigning reviewers based on changed files. For example, any changes in the src/auth/ directory automatically assign team-auth and senior-dev as reviewers. This speeds up the process and ensures the right people see the PR.

Updating a PR Based on Reviews

After receiving reviewer comments, the developer makes fixes in the same feature branch and pushes new commits — the PR updates automatically. It is important not to rewrite history (rebase) in a published feature branch if the PR is already open, as this breaks links to specific commits in comments.

# Make changes based on reviewer comments
git checkout feature/biometric-auth
# fix the code
git commit -m "fix: handle biometric timeout per review"
git push

# PR will update automatically
# After approval — merge the PR via GitHub interface

The Code Review Process

Code review is a central element of a Pull Request. The reviewer checks the changes for correctness, code style, security, and architectural consistency. A quality review not only prevents bugs but also spreads knowledge about the codebase within the team.

Google’s Engineering Practices (2025) recommend the following code review principles: the reviewer should understand the context of changes, give specific recommendations instead of general remarks, and separate technical and stylistic comments. Review time should not exceed 24 hours from the moment the PR is created.

For mobile development, code review includes specific checks: compatibility with targetSdk, correct lifecycle handling (Android) / view lifecycle (iOS), absence of memory leaks (LeakCanary, Instruments), dark theme support, and localization. These checks can be automated through linters and Detekt/ktlint.

Types of Comments

PR platforms support three types of comments: general (to the entire PR), inline (to a specific line of code), and suggestions (with replacement code). Suggestions allow applying changes with one click, speeding up the process and reducing the number of iterations.

After all comments are resolved and CI checks pass, the reviewer sends an approval (Approved). The PR can be merged. GitHub and GitLab support branch protection rules: required number of approvals, mandatory CI checks, and prohibition of pushing to main without a PR. For mobile projects, branch protection also includes build verification: a PR cannot be merged if the application does not build (gradle build failed / xcodebuild failed).

Conflict Resolution in PR

Merge conflicts in a Pull Request are a common situation in active team work. Platforms offer conflict resolution through the web interface (for simple conflicts) or recommend resolving locally. GitHub Actions automatically checks mergeability with each push to the feature branch and marks the PR as conflicted if merging is not possible.

Pull Request Best Practices

Effective Pull Requests speed up code review and reduce the number of bugs. A SmartBear study (2025) showed that PRs up to 200 lines of code receive 2 times more meaningful comments than PRs over 1000 lines, and review time is reduced by 3 times.

• Small PRs — optimal size is 100–300 lines. Break large PRs into logical parts: each PR solves one task. This simplifies review and reduces the likelihood of conflicts
• Clear description — title according to Conventional Commits (feat:, fix:, refactor:), body contains “what and why” rather than “how” (the code speaks for itself). Template: goal → changes → testing → related issues
• Fast feedback — review within 24 hours. If a PR waits more than a day, the team loses context and the number of merge conflicts grows
• Automation — linters, formatters, and tests should run automatically when a PR is created. Do not allow merging PRs with red CI checks
• Draft PR — use for early architecture discussion. Draft PR does not require review and cannot be merged, but allows showing code to colleagues at an early stage

Additional practices: do not create PRs on Friday evening (no one will review until Monday), request review from 1–2 people (more slows down the process without improving quality), use squash merge to compress history before merging. For mobile projects, it is also recommended to add a link to the test build (Firebase App Distribution / TestFlight) in the PR description so the reviewer can verify changes in the running application.

Pull Request on Different Platforms

The main platforms for working with Pull Requests are GitHub, GitLab, and Bitbucket. Despite the shared concept, each has features worth considering when choosing a tool for the team.

GitHub is the most popular platform with the largest community, Actions for CI/CD, and an extensive application ecosystem (GitHub Marketplace). GitLab features built-in CI/CD and full self-hosted deployment capability. Bitbucket is tightly integrated with Jira and the Atlassian ecosystem, popular in corporate environments.

For mobile development, the choice of platform is often determined by CI/CD capabilities: GitHub Actions supports macOS runners for iOS builds, GitLab has built-in runners for iOS/Android, Bitbucket integrates well with Firebase Test Lab. Regardless of the platform, the PR process remains the same: branch → review → CI → merge.