Collaboration — pull requests and code review
On a team nobody straight to main. , , open a , get reviewed, . This is the loop every software team runs on.
What you'll learn
- You can run the branch → PR → review → merge 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 commit directly to main. You branch, do the work, push 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 GitLab 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 several times faster. And keep pull requests small: past about 300 lines, reviewers stop reading carefully and 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 (GitHub ) lets you create, list, and check out pull requests without leaving the .
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.
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.