Pull Request

A Pull Request (PR) is the core mechanism modern development teams use to review and integrate code changes. It is far m

A Pull Request (PR) is the core mechanism modern development teams use to review and integrate code changes. It is far more than a button that triggers a merge; it is a dedicated space for discussion, verification, and knowledge sharing around a proposed change. On GitLab, the equivalent concept is usually called a Merge Request (MR), but the underlying process is essentially the same. A well-defined PR workflow reduces the likelihood of defects reaching the main branch and improves long-term code maintainability.

A typical PR includes the following elements:

  • Source branch: The branch containing the new changes, such as feature/user-login.
  • Target branch: The branch receiving the changes, commonly main, master, or develop.
  • Author: The developer who creates the PR and drives the change toward integration.
  • Reviewers: Team members who check the code for correctness, readability, security, and performance.
  • CI/CD: Automated pipelines that run tests, builds, and static analysis.
  • Merge: The act of integrating the source branch into the target branch.

Preparing Your Branch

Before starting development, synchronize with the target branch and create an isolated feature branch:

git checkout main
git pull origin main
git checkout -b feature/user-login

Use descriptive branch prefixes to signal the type of change. Common conventions include feature/ for new functionality, fix/ for bug fixes, hotfix/ for urgent production patches, and docs/ for documentation updates. These prefixes make it easier to scan branch lists and understand the scope of work at a glance.

Committing and Pushing Changes

After completing the modifications, commit with a message that clearly explains the purpose of the change:

git add src/login.js
git commit -m "feat: add user login endpoint"
git push -u origin feature/user-login

Following a convention such as Conventional Commits helps keep history readable. Prefixes like feat:, fix:, docs:, and refactor: categorize the nature of each commit. Commits should remain small and focused; avoid bundling unrelated fixes into a single PR, as this complicates review and makes future rollbacks riskier.

Opening a Pull Request

On GitHub, GitLab, or similar platforms, click Compare & pull request, select the source and target branches, and submit. The title should be concise and specific. The description should cover the background, the changes made, how to test them, and the expected impact.

A useful description template might look like this:

## Changes
- Add user login endpoint
- Add input parameter validation

## Testing
- Run `npm test`
- Manually verify successful and failed login scenarios

## Related Issue
Closes #123

If the work is still in progress, open a Draft PR (or Work in Progress PR) to signal that the change is not yet ready for review or merging.

Code Review and Automated Checks

Reviewers typically focus on several areas:

  • Whether the functionality works correctly and edge cases are handled.
  • Error handling, security considerations, and performance implications.
  • Test coverage for critical paths.
  • Naming, structure, and overall readability.
  • Duplicate code or unnecessary dependencies.

The author should respond to comments promptly and push new commits as needed. If CI fails, the author must fix the failures before the PR can move forward. Keep discussions centered on the code rather than the person, and avoid emotional or accusatory language.

Syncing with the Target Branch and Resolving Conflicts

If new commits land on the target branch while the PR is open, conflicts may arise. One way to integrate the latest changes is to rebase:

git checkout main
git pull origin main
git checkout feature/user-login
git rebase main
# Resolve any conflicts, then:
git add .
git rebase --continue
git push --force-with-lease

Alternatively, you can merge the target branch into your feature branch using git merge main. When force-pushing after a rebase, prefer --force-with-lease over --force; the former is safer because it prevents overwriting work that others may have pushed to the same remote branch.

Merging the Pull Request

Before merging, verify the following:

  • All CI pipelines have passed.
  • At least one reviewer has approved the change.
  • No unresolved review comments remain.
  • The feature branch is up to date with the target branch.
  • Related issues are correctly linked.

Teams commonly choose among three merge strategies:

  1. Merge commit: Preserves the complete branch history and creates an explicit merge commit. Suitable for long-lived branches.
  2. Squash and merge: Collapses all commits on the feature branch into a single commit on the target branch. Produces a cleaner, simpler history.
  3. Rebase and merge: Replays commits onto the target branch for a linear history without a merge commit.

After merging, clean up the branch both remotely and locally:

git push origin --delete feature/user-login
git checkout main
git pull origin main
git branch -d feature/user-login

Best Practices for Pull Requests

  • Keep PRs small and focused; solve one problem at a time.
  • Write clear titles and descriptions that explain both the why and the how.
  • Test changes locally before opening a PR.
  • Use automated testing, linting, and security scanning as quality gates.
  • Protect the main branch to prevent direct pushes.
  • Review teammates' PRs promptly to maintain a positive collaboration cycle.
  • For large changes, use design documents or Draft PRs to align on approach early.

Conclusion

The Pull Request workflow connects development, review, testing, and merging into a traceable collaboration loop. By following a consistent process, teams can catch defects earlier, reduce merge conflicts, and ensure every change is documented and accountable. Tools may evolve, but the core principles remain the same: small increments, thorough review, automated validation, and clear communication.