Pull Requests

Introduction

A pull request is a hosted conversation around a topic branch: discussion, line-by-line review, automated CI checks and a final merge button.

Beginner analogy: think of Git as a "save game" system for your code — every commit is a checkpoint you can revisit, branches are alternate timelines you can explore safely, and a remote like GitHub is the cloud save your whole team can sync with.

In this lesson we will walk through Pull Requests step by step, connect the command to Git's internal model, practice a realistic team scenario, and learn the failure modes that matter in production repositories.

Purpose of this lesson

The goal is to make Pull Requests operationally useful: you should know when to apply it, which part of Git state it changes, how it affects teammates, and how to recover if the workflow goes wrong.

Understanding the topic

Use this in collaborative engineering where Git is also a coordination system. The goal is to create changes that are small enough to review, tested enough to trust, and traceable enough to audit months later.

Core concepts to understand:

• Clear definition and mental model of pull requests, including which Git layer it changes.
• How the working tree, staging area, local repository, branch refs, and remote refs can differ at the same time.
• How pull requests changes review, CI/CD, release notes, rollback, and team coordination.
• Safety nets: reflog, rescue branches, revert, --force-with-lease, and protected branches.
• Risk patterns: rewriting public history, committing secrets, resolving conflicts carelessly, and letting branches drift for weeks.
• Production context: what this looks like in a repository with required reviews, CI gates, release tags, and audit logs.

Visual explanation

Use this architecture view to reason about where the change lives:

Developer Code Changes
        |
        v
Working Directory
        |
        v
git add  ->  Staging Area
        |
        v
git commit -> Local Repository
        |
        v
git push -> Remote Repository
        |
        v
Team Collaboration

Step-by-step explanation

1. Make the local branch tell a complete story: focused commits, tests updated, no secrets, and a clear commit or PR message.
2. Push to a remote branch and verify the hosted diff, branch target, CI status, required reviewers, and linked issue.
3. Respond to review by adding follow-up commits or amending only when the branch is private and your team expects a clean stack.
4. Merge using the repository policy: squash for a clean main history, merge commits for preserving branch topology, or rebase merge for linear history.
5. Confirm the merge triggered the expected deployment, release, changelog, or downstream automation.

Syntax reference

Visual workflow / architecture:

Developer Code Changes
        |
        v
Working Directory
        |
        v
git add  ->  Staging Area
        |
        v
git commit -> Local Repository
        |
        v
git push -> Remote Repository
        |
        v
Team Collaboration

Informative example

Hands-on commands you can copy-paste:

Pull requests are the heartbeat of team collaboration: they bundle a topic branch with discussion, CI results and reviewer approvals before code lands on main.

# Pull request flow with the GitHub CLI
gh pr create --base main --head feature/login \
  --title "Add login form" --body "Closes #42"

# Review feedback → push more commits
git commit --amend
git push --force-with-lease

# Merge with a clean squash
gh pr merge --squash --delete-branch

Sample terminal output:

Creating pull request for feature/login into main
https://github.com/org/repo/pull/57
✓ Squashed and merged pull request #57
✓ Deleted branch feature/login

Walk-through: notice how Git always prints what changed and where the new state lives — in the working directory, staging area, local .git store, or on the remote. Reading these messages carefully is the difference between a senior Git user and a junior one who fights the tool.

Real-world use

A SaaS team opens a PR for every change. GitHub links the issue, runs CI, requests CODEOWNER review, creates a preview environment, and records the final merge SHA. Pull Requests is the collaboration layer around the commit graph.

Enterprise use cases

In an enterprise repository, Pull Requests is supported by branch protection, CODEOWNERS, signed commits, required status checks, secret scanning, audit logs, and a documented rollback process. The professional standard is not "I know the command"; it is "the workflow is safe for hundreds of contributors and recoverable during an incident."

Best practices

• Write commit messages in the type(scope): summary Conventional Commits style — feat(auth): add JWT refresh.
• Pull (or rebase) main before starting any new work to avoid painful conflicts later.
• Keep branches short-lived (under 2 days) and pull requests under 400 lines for fast reviews.
• Always use --force-with-lease instead of --force when pushing rewritten history.
• Never commit secrets, build artifacts, .env files or node_modules — add them to .gitignore.

Common mistakes

• Force-pushing to a shared branch — wipes teammates' work and is hard to recover from.
• Committing huge binary files into Git — repository balloons forever; use Git LFS instead.
• Resolving a merge conflict by accepting all of one side without reading the other — silent regressions.
• Working directly on main — bypasses code review and breaks the deployable contract.

Debugging tips

• Check git remote -v, git branch -vv, and git status -sb before assuming the remote is wrong.
• Authentication failures usually come from expired tokens, missing SSH keys, wrong account, or credential-helper cache problems.
• A rejected push is often protecting you from overwriting remote work; fetch, inspect, integrate, then push again.

Optimization strategies

• Make the common path boring: clear branch names, consistent commit messages, protected main, and predictable PR policy.
• Automate checks that humans forget: formatting, secret scanning, tests, signed commits, and branch protection.
• Use Git's safety nets intentionally, especially reflog, revert, and --force-with-lease.

Advanced interview questions

Hands-on exercise

Build a disposable lab for Pull Requests. Create a branch, make one intentional change, inspect the diff, commit it, then introduce one realistic mistake and recover. The exercise is complete only when you can explain which layer changed: working tree, index, local branch, remote branch, or object database.

Suggested lab directory: git-pull-requests-lab.

mkdir git-pull-requests-lab
cd git-pull-requests-lab
git init
git switch -c practice/pull-requests
echo "first change" > notes.txt
git status -sb
git add notes.txt
git commit -m "practice: explore pull-requests"
git log --oneline --graph --decorate --all

Summary

Pull Requests is valuable when it makes history easier to understand, collaboration safer, and recovery faster. Treat Git as both a local database and a team operating system: inspect state before changing it, keep history useful, and automate the rules that protect production.