Module 7: Pull Requests & Collaboration (Hands-on!)¶
🎯 What you'll learn: What Pull Requests are, why they exist, how to create one, and the GitHub Flow workflow that professional teams use every day.
🔧 Hands-on module! You'll create a real Pull Request on GitHub.
What is a Pull Request (PR)?¶
In Module 6, you merged branches locally using git merge. A Pull Request is the GitHub way of doing the same thing — but with a review step in between.
A PR is a request to merge your changes into another branch. It says:
"Hey team, I made these changes on my branch. Can someone review them before we merge into main?"
The Analogy — Restaurant Quality Control 🍽️¶
Remember the Cloud Café kitchen analogy?
Without PR (Module 6): The chef experiments in the test kitchen, then adds the dish directly to the main menu. No one checks it first.
With PR (Module 7): The chef experiments, then puts the dish on the tasting counter ✅. The restaurant manager tastes it, gives feedback ("needs more salt"), and only THEN does it go on the main menu.
Without PRs: With PRs:
Branch → Merge directly Branch → PR → Review → Merge
Chef cooks → Main menu Chef cooks → Tasting → Feedback → Main menu
(no quality check) (quality assured!)
The Pull Request Workflow¶
graph LR
A["1️⃣ Create<br/>branch"] --> B["2️⃣ Make<br/>changes"]
B --> C["3️⃣ Push to<br/>GitHub"]
C --> D["4️⃣ Open<br/>Pull Request"]
D --> E["5️⃣ Review<br/>& discuss"]
E --> F["6️⃣ Merge<br/>& delete branch"]
style A fill:#1a1a2e,stroke:#66ffff,color:#fff
style B fill:#1a1a2e,stroke:#66ffff,color:#fff
style C fill:#1a1a2e,stroke:#66ffff,color:#fff
style D fill:#1a1a2e,stroke:#ffff66,color:#fff
style E fill:#1a1a2e,stroke:#ffff66,color:#fff
style F fill:#1a1a2e,stroke:#66ff66,color:#fff| Step | Where | What Happens |
|---|---|---|
| 1. Create branch | Local (CLI or Desktop) | Start a new feature/fix |
| 2. Make changes | Local | Edit, add, commit |
| 3. Push to GitHub | Local → GitHub | Send your branch to GitHub |
| 4. Open a PR | GitHub.com | Propose your changes for review |
| 5. Review & discuss | GitHub.com | Team reviews, comments, requests changes |
| 6. Merge & cleanup | GitHub.com | Merge into main, delete branch |
Anatomy of a Pull Request¶
When you open a PR on GitHub, it shows:
┌─────────────────────────────────────────────────────┐
│ Pull Request #1: "Add desserts to menu" │
├─────────────────────────────────────────────────────┤
│ │
│ From: desserts-menu → Into: master │
│ Author: susanthgit │
│ │
│ 📝 Description: │
│ "Added a new desserts section with cakes and │
│ pastries. Prices based on supplier quotes." │
│ │
│ 📊 Changes: 1 file changed, 8 additions │
│ │
│ ✅ No conflicts with master │
│ │
│ [Merge pull request] [Close] │
└─────────────────────────────────────────────────────┘
PR Tabs¶
| Tab | What It Shows |
|---|---|
| Conversation | Description, comments, review status |
| Commits | All commits in this branch |
| Files changed | Line-by-line diff (like git diff) |
GitHub Flow — The Simple Workflow¶
GitHub Flow is the most popular workflow for teams. It's simple:
mainis always deployable (working, tested)- Create a branch for every change
- Push the branch to GitHub
- Open a Pull Request
- Review and discuss
- Merge into main
- Delete the branch
main: ────●────●────●────────────●──── (always stable)
\ /
feature: ●────●────●────PR─── (work happens here)
↑
review + merge
💡 This is exactly how your websites work! You push to
main, and GitHub Actions auto-deploys. If you used branches + PRs, you'd have a review step before deploying.
Why PRs Matter — Even for Solo Developers¶
You might think: "I work alone. Why do I need PRs?" Here's why:
| Benefit | For Teams | For Solo (You!) |
|---|---|---|
| Code review | Team catches bugs | You review your own work (fresh eyes) |
| History | Who approved what | Clear record of why you made changes |
| CI/CD checks | Tests run automatically | GitHub Actions runs before merge |
| Rollback | Easy to revert a PR | Easy to undo a bad change |
| Documentation | PR description explains the change | Your future self will thank you |
Hands-on: Create Your First Pull Request!¶
Step 1: Create a branch and make changes¶
In your practice terminal:
cd C:\ssClawy\git-practice\cloud-cafe
# Create a new branch
git switch -c add-desserts
# Add a desserts section
Add-Content menu.md "`n`n## Desserts`n- Chocolate Cake - 8.00`n- Cheesecake - 7.50`n- Brownie - 5.00"
# Stage and commit
git add menu.md
git commit -m "Added desserts section to menu"
Step 2: Push the branch to GitHub¶
The -u flag sets up tracking (so future pushes just need git push).
Step 3: Open a PR on GitHub¶
After pushing, Git shows a URL to create a PR. Or go to:
github.com/susanthgit/cloud-cafe → you'll see a yellow banner:
"add-desserts had recent pushes — Compare & pull request"
Click it! Then: 1. Title: "Added desserts section" 2. Description: "New desserts section with Chocolate Cake, Cheesecake, and Brownie." 3. Click "Create pull request"
Step 4: Review the PR¶
On the PR page: - Click "Files changed" tab → see the diff - You can add comments on specific lines!
Step 5: Merge the PR¶
Click "Merge pull request" → "Confirm merge"
Then click "Delete branch" to clean up.
Step 6: Pull the merge locally¶
Back in your terminal:
Your local repo now has the merged changes!
PRs in GitHub Desktop¶
| Step | GitHub Desktop |
|---|---|
| Create branch | Branch → New Branch |
| Make changes + commit | Changes tab → commit |
| Push | "Push origin" button |
| Create PR | "Create Pull Request" button → opens GitHub.com |
| Merge | Done on GitHub.com |
| Pull after merge | "Fetch origin" / "Pull origin" |
✅ Module 7 Summary¶
┌──────────────────────────────────────────────────────┐
│ Module 7 Recap │
├──────────────────────────────────────────────────────┤
│ │
│ Pull Request = request to merge + review step │
│ │
│ Workflow: │
│ branch → changes → push → PR → review → merge │
│ │
│ GitHub Flow: │
│ main is always deployable, work happens on branches │
│ every change goes through a PR │
│ │
│ PRs are useful even for solo developers: │
│ review, history, CI checks, rollback │
│ │
│ ➡️ Next: Module 8 — Real-World Git │
└──────────────────────────────────────────────────────┘
🧪 Module 7 Quiz¶
Q1: What is the difference between git merge (Module 6) and a Pull Request?
Both merge branches. git merge does it locally with no review. A Pull Request does it on GitHub with a review step — others can see the changes, comment, request modifications, and approve before merging. PRs add a quality control layer.
Q2: In GitHub Flow, should you ever commit directly to main?
Ideally, no. In GitHub Flow, main should always be stable and deployable. All changes should come through branches and Pull Requests. In practice, small fixes sometimes go directly to main, but the best practice is always using PRs.
Q3: After merging a PR on GitHub, your local repo doesn't have the merge. What do you run?
git pull while on the master/main branch. This fetches the merge commit from GitHub and updates your local copy.
Q4: Why are PRs useful even if you work alone?
PRs provide: (1) A review step where you can catch your own mistakes with fresh eyes, (2) A clear history of why changes were made, (3) CI/CD checks (GitHub Actions) run before merge, (4) Easy rollback if something goes wrong.
➡️ What's Next?¶
In Module 8: Real-World Git, you'll learn about .gitignore, README files, GitHub Actions, and decode YOUR actual website deployment workflow!