Session 15: Coach notes

Goal of this session

At the end of this session a ninja can:

Work together with a buddy on the same GitHub repo (collaborator access).
Push a feature branch to GitHub.
Open a pull request with a structured description (what, why, how to test).
Review a buddy’s PR: read the diff, give specific feedback on lines, approve or request changes.
Handle feedback by pushing extra commits to the feature branch.
Merge an approved PR and clean up the branch (locally and on GitHub).

This is the last session of the Git series.

Preparation (45 min before the session)

Form pairs. Ninjas work in pairs. Decide beforehand who works with whom. Take into account: GitHub account active or not, Git experience, age. An experienced ninja with a beginner often works well: the experienced ninja learns by explaining.
WiFi check. This session needs a stable internet connection for all laptops at the same time. Test it beforehand.
Have a demo repo ready. Make sure you have a repo on which you can demo the full PR workflow on the projector: a feature branch, opening a PR, placing a comment, merging a PR.
Your own GitHub account at hand. You have to be able to send and accept collaborator invitations during the demo.
Backup: fork workflow explanation. If collaborator access doesn’t work for whatever reason (email not reachable, permission problems), you can explain the fork workflow as a fallback. See the “Practical pitfalls” section below.

Schedule (3 hours)

Time	Activity
0:00 to 0:15	Welcome, forming pairs. Recap: branches, pushes, GitHub
0:15 to 0:40	Projector: full PR workflow (branch, push, open PR, review, merge, clean up)
0:40 to 0:55	Pairs: setting up collaborator access + cloning the repo
0:55 to 1:15	Break
1:15 to 1:55	Round 1: author builds feature, opens PR (reviewer waits/looks along)
1:55 to 2:10	Reviewer does the review, gives feedback
2:10 to 2:25	Author handles feedback, reviewer approves, merge
2:25 to 2:45	Swap roles: round 2
2:45 to 3:00	Showcase, wrap-up, looking back at the whole Git/GitHub series

Common questions

“What’s the difference between a collaborator and a fork?” Collaborator = you have direct push access to the repo. You work on branches in the same repo. Fork = you make a copy of someone’s repo into your account. You work in your copy, and open a PR from your fork to the original. Collaborator is easier for beginners; fork is how open source works.

“My buddy can’t accept my invitation.” Check: does the reviewer have access to email? GitHub sends the invitation by email. Alternative: the reviewer can go to https://github.com/AUTEUR_USERNAME/repo-naam/invitations to accept the invitation directly.

“Do I have to merge every PR with a merge commit?” GitHub gives three options: merge commit, squash merge, rebase merge. For now: use the default (merge commit). That keeps the full history of your feature branch. Squash and rebase are more advanced and you learn them later.

“What if I accidentally work on the wrong branch?” Always check with git status which branch you’re on before you begin. If you already made commits on the wrong branch: git stash your changes, switch to the right branch, and git stash pop.

“Can I undo a PR after merging?” You can undo a commit with git revert <commit-hash>. This makes a new commit that undoes the changes. This is safer than rewriting the history, especially on master.

Hints for Stretch and Expert

Stretch: PR template: GitHub can show a template every time someone opens a PR. Create a file .github/pull_request_template.md in your repo containing:

## What

## Why

## How to test

GitHub fills this in automatically for every new PR.

Expert: draft PR: If you want to open a PR early for feedback, even though the code isn’t finished yet, make a draft PR. Click the arrow next to “Create pull request” → “Create draft pull request”. Draft PRs can’t be merged by accident.

Expert: reviewing multiple commits: In the “Files changed” tab you can look at what changed per commit. Click the commit dropdown above the diff. This is handy when a PR has several commits and you want to look at them one by one.

Recap: looking back at the whole series

At the end of this session you can briefly look back at what ninjas learned in five sessions:

Session	What you can do
11	`git init`, `add`, `commit`, `status`, `log`, `diff`, `.gitignore`
12	`branch`, `switch`, `merge`, solving merge conflicts
13	GitHub: account, `remote`, `push`, `pull`, `clone`
14	Good commit messages, branch naming, `stash`, pull-before-push
15	Pull requests: opening, reviewing, handling feedback, merging

This is the toolbox of every professional developer. Ninjas don’t have to master everything perfectly, but they have to know that it exists, and be able to apply the basics themselves.

Practical pitfalls

Collaborator access doesn’t work. Solution: use the fork workflow as a fallback. The reviewer forks the author’s repo, clones the fork, makes a branch, and opens a PR from the fork to the original. This needs no collaborator access. It’s a bit more complex, but useful to know.
Merge conflicts during a PR. If master has changed since the feature branch was split off, a merge conflict appears when merging the PR. GitHub shows a warning. The author has to merge master into the feature branch locally, solve the conflict, and push again. Help ninjas with this; merge conflicts in a PR context are more confusing than local conflicts.
PRs that are too big. A PR that changes 30 files is hard to review. Encourage ninjas to keep PRs small: one feature, one PR. If a feature is too big, split it into several smaller PRs.
Forgetting to pull after the merge. After merging on GitHub the author has to do git pull on master locally. Otherwise they work on an outdated master and problems appear with the next branch.