Git & GitHub

GitHub & Pull Requests

3 min read
Focus: GIT
⚡

TL;DR — Quick Summary

  • A Pull Request is a proposal to merge your branch into another — it enables code review, discussion, and CI checks.
  • Workflow: branch → commit → push → open PR → review → merge.
  • Fork = copy a repo to your account (for external contributions). Branch = diverge within the same repo (for internal work).
  • Keep PRs small, focused, and well-described — they're the unit of professional code collaboration.

Lesson Overview

🐙 GitHub: Where Teams Build Together

GitHub transforms Git from a local tool into a full collaboration platform. At its center is the Pull Request (PR) — the mechanism through which code is proposed, reviewed, discussed, and merged into a shared codebase.

🔀 What is a Pull Request?

A Pull Request is a formal request to merge changes from one branch into another. It's not a Git feature — it's a GitHub (and GitLab/Bitbucket) feature built on top of Git. A PR enables:

  • 📋 Code Review: Teammates review changes before they hit main
  • 💬 Discussion: Comment on specific lines of code
  • ✅ CI/CD: Automated tests run against the proposed changes
  • 📜 Audit Trail: Every change is documented, discussable, and searchable

🍴 Forking vs. Branching

  • Branch: Used when you have write access to the repository. You create a branch, push it, and open a PR within the same repo.
  • Fork: Used when contributing to a repo you don't own (e.g., open source). You fork the repo to your own account, make changes, and open a PR from your fork back to the original repo.

Pull Requests are the cornerstone of professional software development. Learning to write a great PR description and give constructive code reviews is as important as writing good code.

Conceptual Deep Dive

The Pull Request workflow is the heartbeat of team development. Here's the golden loop:
  1. Create a feature branch from main
  2. Write code and commit it
  3. Push the branch to GitHub
  4. Open a Pull Request on GitHub
  5. Teammates review, comment, and request changes
  6. You address feedback with new commits
  7. Tests pass, approval is given
  8. PR is merged into main — branch is deleted
This loop ensures no untested, unreviewed code ever reaches your production branch.

Implementation Lab

The Complete Pull Request Workflow
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# 1. Start from an up-to-date main
git checkout main
git pull origin main
 
# 2. Create a feature branch
git checkout -b feature/add-dark-mode
 
# 3. Make your changes and commit
git add src/theme.css src/ThemeToggle.jsx
git commit -m "Add dark mode toggle with CSS variables"CSS variables"
git add tests/theme.test.js
git commit -m "Add tests for dark mode toggle"for dark mode toggle"
 
# 4. Push to GitHub
git push -u origin feature/add-dark-mode
 
# 5. Go to GitHub.com → your repo will show a banner:
# 'feature/add-dark-mode had recent pushes. Compare & pull request'
# Click it and fill in the PR description.
 
# 6. After review, if changes requested — make them locally:
git add src/theme.css
git commit -m "Fix: use prefers-color-scheme for default theme"for default theme"
git push  # updates the existing PR automatically
 
# 7. After approval and merge on GitHub:
git checkout main
git pull origin main  # your changes are now in main
git branch -d feature/add-dark-mode  # clean up local branch
Fork & Contribute to Open Source
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
# 1. On GitHub, click 'Fork' on the original repo
# This creates: github.com/YOUR-USERNAME/original-repo
 
# 2. Clone YOUR fork (not the original)
git clone https://github.com/YOUR-USERNAME/original-repo.gitUSERNAME/original-repo.git
cd original-repo
 
# 3. Add the original repo as 'upstream' remote
git remote add upstream https://github.com/ORIGINAL-OWNER/original-repo.gitOWNER/original-repo.git
git remote -v
# origin    https://github.com/YOU/original-repo.git (your fork)(your fork)
# upstream  https://github.com/ORIGINAL-OWNER/original-repo.git (original)OWNER/original-repo.git (original)
 
# 4. Create a branch, make changes, push to YOUR fork
git checkout -b fix/typo-in-readme
# ... edit, add, commit ...
git push origin fix/typo-in-readme
 
# 5. On GitHub, open a PR from your fork's branch → original repo's main
 
# 6. Keep your fork up to date with the original:
git fetch upstream
git checkout main
git merge upstream/main
git push origin main

Pro Tips — Senior Dev Insights

1

Use PR templates on GitHub (.github/pull_request_template.md) to enforce a standard PR format across your team.

2

Mark a PR as Draft while you're still working on it — this signals 'not ready for review' while still sharing progress.

3

Use git push --force-with-lease instead of --force when rebasing a PR branch — it checks that nobody else pushed to the branch since your last fetch.

4

Squash-merging PRs into main keeps your main branch history clean — one PR = one commit, with a meaningful message.

Common Developer Pitfalls

!

Opening a giant PR with hundreds of files changed — reviewers can't review it effectively and it becomes a bottleneck.

!

Not writing a PR description — reviewers have to guess the context, making review slower and less accurate.

!

Merging your own PRs without any review — this defeats the entire purpose of the PR workflow.

!
Not keeping your PR branch up to date with main — letting it fall behind leads to major conflicts at merge time.

Interview Mastery

A branch is a divergent line of development within the same repository — you need write access to the repo. A fork is a complete copy of the repository under your own GitHub account — no write access to the original needed. Forks are used primarily for contributing to open-source projects where you don't have write access to the original.

The Pull Request is automatically updated with the new commits. You don't need to close and reopen it. This is how you respond to code review feedback — push new commits addressing the feedback, and the reviewer can see the changes in the same PR thread. The conversation and review history is preserved.

Merge commit: preserves all branch commits + adds a merge commit. Full history retained. Squash and merge: collapses all branch commits into a single commit on main. Cleanest history. Rebase and merge: replays branch commits onto main without a merge commit. Linear history without squashing. Most teams choose squash for feature branches to keep main history readable.

Real-World Blueprint

"A developer at a company adds a new checkout feature. They push a branch with 3 commits, open a PR, and write a clear description with screenshots. A senior developer leaves 5 comments — 3 style issues, 1 performance concern, and 1 bug they spotted. The developer addresses all of them, pushes new commits, and responds to each comment. After CI passes and 2 approvals, the PM merges it. The whole conversation is preserved forever — 6 months later, when a bug appears, the team can trace exactly why that code was written that way."

Hands-on Lab Exercises

1
Create a repo on GitHub, push a feature branch, and open a Pull Request against main — write a clear PR description.
2

Fork any public repo on GitHub, clone your fork, make a small change, push it, and open a PR to the original repo.

3
On a PR you've opened, practice adding the upstream remote and syncing your fork with git fetch upstream.
4

Review a PR: leave a comment on a specific line of code, request a change, and then approve it after the change is made.

Real-World Practice Scenarios

Your PR has been open for 3 days and main has received 20 new commits. Your PR now has merge conflicts. How do you update your PR?

A code reviewer left a comment saying your function is too complex. How do you address their feedback in the existing PR?

You open-source your side project and receive a PR from a stranger on the internet. What do you look for during code review?

Your team wants to ensure no code goes to main without at least 2 approvals and passing CI tests. How do you enforce this on GitHub?