Stage 7 - Collaboration with Pull Requests
task-service now exists on GitHub. The team now expects review before merge. This is where pull requests become the practical control point between local git work and stable main.
Pull request = proposed merge with context
A PR is not only a request button. It is a review workspace containing:
- commit list,
- changed files,
- comments,
- checks status,
- history of updates.
In other words, PR is where your branch changes are negotiated before integration.
Branch workflow on task-service
From remote main, create a feature branch, apply a clear change, and push it:
git switch main
git pull
git switch -c feature/task-export
Apply one focused change. Create task-service-export.json in your editor with this content:
{"version":"1.0","export":"json"}
Then commit and push it:
git add task-service-export.json
git commit -m "feat: add export format contract file"
git push -u origin feature/task-export
Create PR in GitHub UI from feature/task-export to main.
Fork workflow vs same-repo workflow
In an internal repo, you usually create branches in the same repository.
In OSS, you might not have write access. Then you:
- fork upstream,
- clone your fork,
- push branch there,
- open PR to original repository.
Both approaches carry the same principle: branch is first local, then remote, then reviewed merge.
Working with review comments
Review comments are part of engineering communication, not criticism.
git switch feature/task-export
# fix comment-required change
git add task-service-export.json
git commit -m "fix: include metadata in export contract"
git push
GitHub automatically updates PR while comments are addressed on the same branch.
| Term | Role in this stage |
|---|---|
| Fork | Your own remote copy when direct push is restricted |
| PR | Shared review room before merge |
| Review comment | Concrete technical feedback tied to location |
| Push after review | New commit that amends same PR content |
When review passes, the merge is often the smallest risk because work arrived as a tested, discussed, and intentional branch.
Review as engineering practice, not bureaucracy
A strong PR is not about more text, it is about reducing future ambiguity. Include three anchors in each PR body:
- what behavior changed,
- what was not changed,
- how to validate quickly.
If your PR has only a broad statement and no validation steps, reviewers spend extra time reconstructing context. In this course scenario, always add a short test command, an example input, or a manual check for task-service.
You can also treat review comments as a product design feedback loop. Instead of arguing over preference, ask: does this change reduce risk for the next developer who will read this commit chain?