GitHub Pull Requests (PR): Drafting, Reviewing & Peer Code Approvals

The Pull Request (PR) is the crown jewel of GitHub collaboration. A pull request is not a Git CLI command; it is a collaborative platform mechanism that notifies teammates: "I have finished developing this feature on an isolated branch. Please review my code diff, discuss architectural decisions, run automated tests, and merge it into main."

Figure 30.1: The End-to-End GitHub Pull Request Lifecycle — Branch Creation, CI Checks, Code Review & Merge.

The 4 Stages of a Pull Request Lifecycle

Stage 1: Opening a Pull Request

1. Push your local feature branch to GitHub: git push -u origin feature/user-auth.
2. Navigate to your repository on GitHub. A yellow banner appears: "feature/user-auth had recent pushes... Compare & pull request". Click it!
3. Verify the base branch (main) and compare branch (feature/user-auth).
4. Write a clear PR title and descriptive summary detailing:
   • What problem this PR solves.
   • Key architectural changes.
   • How reviewers can manually test it.
   • Linked issues (e.g., "Fixes #104").
5. Click Create pull request (or choose "Create draft pull request" if your work is still in progress).

Stage 2: Automated CI/CD Status Checks

As soon as a PR opens, configured GitHub Actions workflows trigger automatically. Virtual runners execute tests, run code linters, check for security vulnerabilities, and verify that the application compiles. Green checkmarks (✓) indicate passing builds, while red X marks (✗) block merging.

Stage 3: Peer Code Review

Reviewers navigate to the Files changed tab to inspect unified or side-by-side diffs. Reviewers can:

• Leave Inline Comments: Hover over any line of code, click the blue + icon, and write constructive feedback or questions.
• Suggest Code Replacements: Click the Insert a suggestion icon to propose exact code edits. The author can commit the suggestion directly with a single click!
• Submit Final Review: Reviewers choose one of three verdicts:
  1. Comment: General feedback without explicit approval or rejection.
  2. Approve: Code is verified, healthy, and ready to be merged.
  3. Request changes: Critical issues must be addressed before merging is permitted.

Stage 4: Merging & Deleting Branch

Once approvals are secured and automated CI checks pass green, an authorized maintainer clicks Merge pull request. GitHub automatically merges the code into main and provides a button to delete the feature branch, keeping the repository tidy.