Collaboration — pull requests and code review
On a team nobody commits straight to main. Branch, push, open a pull request, get reviewed, merge. This is the loop every software team runs on.
What you'll learn
- You can run the → → review → loop
- You can write a pull request that's easy to review
- You know the flow for contributing to someone else's project
On a team you don't directly to main. You branch, do the work, the branch, and open a pull request asking for it to be merged. A reviewer reads it, leaves comments, and once it passes, it goes in. and both work this way, and so does almost every company you'll join.
A pull request isn't a place to have your inspected — it's where you share intent. Put what you did in the title, and why it's needed plus how you verified it in the body, and review gets much faster. And keep pull requests small: past about 300 lines, reviewers find it hard to read carefully and tend to just approve.
When review comments come in, add commits to the same branch and push again — the pull request updates itself. To contribute to someone else's public , fork it to your account first, branch inside your fork, and open the pull request against the original. The gh command () lets you create, list, and check out pull requests without leaving the .
Understand it easily
A pull request is like handing in homework to be checked before it goes up on the class wall. Teammates read the changes and leave comments, and only after approval is it merged into .
Commands for this step
Don't just read them — type them into a real terminal. Your hands have to remember, not your eyes.
git switch -c fix/session-expiry- Open a branch for the work. Name it after what it does.
git push -u origin fix/session-expiry- Push the branch to the so a pull request can be opened from it.
gh pr create --fill- Create a pull request from the terminal, filling title and body from your commits.
gh pr checkout <number>- Check out someone else's pull request locally to test it before approving.
Common mistake and how to fix it
Opening one huge pull request with many unrelated changes. Reviewers cannot read it well, so mistakes slip through. Keep one purpose per pull request, and if a change grows large, split it into smaller branches.
You mark this yourself. Nothing is graded here.
Mark this step as understood?
This cannot be undone yet, so mark it only when you really understand.
Marked as understood
You mark this yourself. Nothing is graded here.