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 branch → PR → review → merge loop
- You can write a pull request that's easy to review
- You know the fork 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. GitHub 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 code 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 repository, fork it to your account first, branch inside your fork, and open the pull request against the original. The gh command (GitHub CLI) lets you create, list, and check out pull requests without leaving the terminal.
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 remote 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.