Giving and receiving review
Understand the idea
Peer comments help first. The teacher's review is what gates merge on the shared starter.
The idea
Review has two layers on the Team Simulation path:
- Peer review — classmates leave comments on the pull request (
git review "…"). Comments are encouraged before the teacher looks. They do not block merge by themselves. - Teacher review — the target owner (your teacher) uses the Maintainer Queue to comment, request changes, approve, or merge. Requesting changes sets status to
changes_requestedand blocks merge until you push a follow-up commit on the source branch (status returns toopen).
git review appends a comment on the latest that involves the repository you have open. Use git review --request-changes "…" only when you mean to block merge until the author updates.
What changes
A peer comment is stored on the request; status stays open. A teacher request-changes flips status to changes_requested. The does not move until the author commits. A follow-up commit on the fork updates the diff and, if status was changes_requested, reopens the request to open.
| Layer | Who | Effect on merge |
|---|---|---|
| Peer comment | Classmates on the thread | None — advice only |
| Request changes | Usually the teacher (target owner) | Blocks merge until a new source commit reopens the PR |
| Approve or merge | Target owner only | Approve records readiness; merge lands commits on the shared starter |
The command
Open the pull request toward the shared starter first. Run git review "Please say who the notes are for" as a peer-style comment. Then edit the file and commit the response on the source branch. The comment stays. The diff moves.
The mistake
Check your graph
The review lives on the pull request. The response, if you committed it, is a new node on the source branch.
Your repository
Leave a peer comment on a pull request aimed at the shared starter, then answer review with a commit.
Step 1
Peer comment
Leave a classmate-style comment. This does not block merge. The teacher’s request-changes / approve / merge actions are what gate landing on the shared starter.
Step 2
Update the file
In the editor, set the README line to: Notes from my fork, for the class.
Step 3
Commit the response
Run git add README.md first. If status was changes_requested, this commit reopens the pull request to open.
The editor edits the working tree. Start a repository and the files appear here.
Commit graph
No commits yet. git init creates the first one.
Quiz
A quick check for understanding. Retry as often as you like; your learning path stays open.
Ready to call this one understood?
Mark this lesson complete to earn 200 XP. You can always revisit it.