TECH **Git & GitHub Pull Requests (PRs): The Zero-Fluff, Hands-On Guide**

Git & GitHub Pull Requests (PRs): The Zero-Fluff, Hands-On Guide

For engineers who need to ship code safely, review changes efficiently, and avoid production fires.

1. What This Is & Why It Matters

A Pull Request (PR) is GitHub’s (and GitLab’s/Azure DevOps’) way of saying: “Hey team, I’ve got some changes ready—can you check them before they merge into the main codebase?”

Why This Matters in Production

• Prevents broken deployments: A bad merge can take down a service (ask any engineer who’s pushed a typo to main at 3 AM).
• Enforces quality: PRs are where code reviews, automated tests, and security scans run before code hits production.
• Documents decisions: PRs create a permanent record of why a change was made (critical for debugging later).
• Enables collaboration: Junior devs get feedback; senior devs catch edge cases before they become outages.

Real-World Scenario

You’re a backend engineer working on a payment processing system. A teammate opens a PR to update the API’s rate-limiting logic. If you merge it without reviewing: - The new logic might block legitimate users (false positives).
- The change could conflict with another team’s work, breaking the checkout flow.
- A missing test could let a bug slip through, causing failed transactions.

PRs are your last line of defense before code hits production.

2. Core Concepts & Components

3. Step-by-Step: Creating, Reviewing, and Requesting Changes

Prerequisites

• A GitHub account (free tier is fine).
• A local Git repo cloned from a GitHub repository.
• Basic Git knowledge (git add, git commit, git push).

Task: Create, Review, and Merge a PR (End-to-End Example)

Scenario: You’re adding a new API endpoint (/health) to a Node.js app. Here’s how to do it the right way.

Step 1: Create a Feature Branch

# Start from the latest main branch
git checkout main
git pull origin main

# Create and switch to a new branch
git checkout -b feature/add-health-endpoint

Why?
- Never work directly on main. Branches isolate changes.
- Branch names should be descriptive (feature/, fix/, docs/ prefixes help).

Step 2: Make Your Changes

Edit server.js:

// Add a new endpoint
app.get('/health', (req, res) => {
  res.status(200).json({ status: 'OK' });
});

Commit the change:

git add server.js
git commit -m "feat: add /health endpoint"

Pro Tip:
- Use Conventional Commits (feat:, fix:, docs:) for clarity.
- Keep commits small and focused (one logical change per commit).

Step 3: Push Your Branch to GitHub

git push origin feature/add-health-endpoint

Why?
- Pushing early lets teammates see your work (even if it’s incomplete).
- Enables CI/CD pipelines to run tests on your branch.

Step 4: Open a Pull Request

1. Go to your repo on GitHub.
2. Click "Pull requests" > "New pull request".
3. Set:
4. Base branch: main
5. Compare branch: feature/add-health-endpoint
6. Click "Create pull request".
7. Fill in the PR template (if your repo has one):
   ``markdown
## Description
Adds a/health` endpoint to check API status.

## Changes
- New /health route in server.js

## Testing
- Manually tested with curl http://localhost:3000/health
- Added unit test in health.test.js (see commit abc123)

## Screenshots (if applicable)
N/A
```

Production Insight:
- A good PR description answers: - What changed? - Why was this change needed? - How was it tested? - Link to related issues (e.g., “Fixes #123”).

Step 5: Request a Review

1. On the PR page, click "Reviewers" in the right sidebar.
2. Select at least one teammate (e.g., @alice).
3. Optionally, add labels (e.g., enhancement, backend).

Why?
- Explicit reviewers reduce bottlenecks (vs. hoping someone notices).
- Labels help triage PRs (e.g., bug vs. feature).

Step 6: Review a PR (As a Teammate)

1. Go to the PR and click the "Files changed" tab.
2. Look for:
3. Logic errors: Does the code do what it claims?
4. Edge cases: What if req is null? What if the DB is down?
5. Style issues: Is the code consistent with the repo’s style guide?
6. Leave specific feedback:
7. ❌ “This is bad.”
8. ✅ “This query could be slow—add an index on user_id.”
9. Use GitHub’s suggested changes feature to propose fixes directly:
   ```diff
10. res.status(200).json({ status: 'OK' });
11. res.status(200).json({ status: 'OK', timestamp: Date.now() });
    ```
12. Click "Request changes" if fixes are needed, or "Approve" if it’s good to merge.

Production Insight:
- Be kind but direct. Code reviews are about the code, not the person.
- Prioritize blocking issues (e.g., security flaws) over nitpicks (e.g., “I prefer single quotes”).

Step 7: Address Feedback

1. Make changes locally:
   bash
# Edit server.js to add the timestamp
git add server.js
git commit -m "fix: add timestamp to /health response"
git push origin feature/add-health-endpoint
2. The PR updates automatically. Reply to comments:
3. “Fixed! Added timestamp as suggested.”
4. If the reviewer requested changes, re-request their review after pushing fixes.

Why?
- GitHub doesn’t notify reviewers of new commits—you must re-request.
- Small, incremental updates make reviews easier.

Step 8: Merge the PR

1. Ensure:
2. All status checks pass (e.g., tests, linting).
3. At least one approval is given.
4. No merge conflicts exist.
5. Click "Merge pull request" and choose a merge strategy:
6. Create a merge commit (default, preserves history).
7. Squash and merge (good for small PRs).
8. Rebase and merge (keeps history linear).
9. Delete the branch (GitHub will prompt you).

Production Insight:
- Never force-merge. If checks fail, fix them first.
- Delete branches after merging to avoid clutter.

4. ? Production-Ready Best Practices

Security

• Require approvals for main: Enable branch protection rules in Settings > Branches.
• Limit admin access: Only leads/managers should have merge rights.
• Scan for secrets: Use GitHub’s secret scanning or tools like gitleaks.
• Review PRs from forks carefully: Malicious actors can submit PRs with hidden payloads.

Cost Optimization

• Short-lived branches: The longer a branch lives, the more merge conflicts it causes.
• Small PRs: Aim for < 200 lines of changes. Large PRs are harder to review.
• Automate checks: Use GitHub Actions to run tests/linting (free for public repos).

Reliability & Maintainability

• Use templates: Create a .github/PULL_REQUEST_TEMPLATE.md to standardize descriptions.
• Link to issues: Use Fixes #123 to auto-close issues when the PR merges.
• Tag stakeholders: Mention @team-frontend or @security for cross-team reviews.
• Document breaking changes: Add a BREAKING CHANGE: footer in commits if the PR changes APIs.

Observability

• Monitor PR cycle time: Long PRs (> 3 days) indicate bottlenecks.
• Track review turnaround: Slow reviews delay releases.
• Log merge events: Use GitHub’s audit log to track who merged what.

5. ⚠️ Common Mistakes & Traps

6. ? Exam/Certification Focus

GitHub certifications (e.g., GitHub Actions) and DevOps exams (e.g., AWS DevOps Pro) test PR workflows. Here’s what to expect:

Typical Question Patterns

1. Branch Protection Rules:
2. Question: “How do you prevent direct pushes to main?”
3. Answer: Enable branch protection and require PRs + approvals.

4. Trap: “Just tell people not to push to main” (not enforceable).

5. Merge Strategies:

6. Question: “When should you use ‘Squash and merge’?”
7. Answer: For small PRs with many commits (keeps main clean).

8. Trap: “Always use rebase” (can cause issues with shared branches).

9. Status Checks:

10. Question: “A PR has failing tests. What do you do?”
11. Answer: Fix the tests before merging.

12. Trap: “Merge anyway and fix later” (violates CI/CD principles).

13. Review Workflow:

14. Question: “A teammate requests changes. What’s the next step?”
15. Answer: Push fixes and re-request their review.

16. Trap: “Merge anyway” (ignores feedback).

17. Draft PRs:

18. Question: “How do you share work-in-progress code for early feedback?”
19. Answer: Open a draft PR.
20. Trap: “Push to main” (breaks the workflow).

7. ? Hands-On Challenge

Challenge: 1. Fork this demo repo (or use your own).
2. Create a branch fix/readme-typo.
3. Fix a typo in the README.md (e.g., change “Hello World” to “Hello GitHub”).
4. Open a PR, request a review from a teammate (or yourself), and merge it.

Solution:

git clone https://github.com/your-username/Hello-World.git
cd Hello-World
git checkout -b fix/readme-typo
# Edit README.md
git add README.md
git commit -m "fix: correct typo in README"
git push origin fix/readme-typo
# Open PR on GitHub, request review, merge.

Why It Works: - Follows the full PR workflow (branch → change → PR → review → merge).
- Demonstrates how small, focused PRs work in practice.

8. ? Rapid-Reference Crib Sheet

9. ? Where to Go Next

1. GitHub Docs: About Pull Requests – Official guide.
2. GitHub’s PR Templates – Standardize PR descriptions.
3. Conventional Commits – Write better commit messages.
4. GitHub Actions for PRs – Automate checks.
5. How to Review Code – Google’s code review guide.