Collaborate on GitHub — track work with issues, contribute to projects you cannot push to via forks, give useful code reviews, and protect the main branch.
Why: issues are GitHub's to-do list and bug tracker. Each issue is a conversation about one task or bug, with a number you can reference from commits and PRs. Note: writing "Closes #14" in a PR description auto-closes issue 14 when the PR merges — a small trick that keeps things tidy.
Create an issue from the terminal (or use the repo's "Issues" tab)
gh issue create --title "Login button misaligned on mobile" \
--body "Steps to reproduce, expected vs actual…"List and view issues
gh issue listgh issue view 14Reference it from a commit so the work links back to the issue
git commit -m "Fix login button alignment (closes #14)"Why: you usually cannot push directly to someone else's repository. A fork is your own personal copy of their repo under your account — you push to the fork, then open a PR back to the original. This is how almost all open source contribution works. Note: "upstream" is the conventional name for the original repo you forked from.
Fork the repo to your account and clone your fork
gh repo fork owner/project --cloneAdd the ORIGINAL repo as a second remote called "upstream"
git remote add upstream https://github.com/owner/project.gitBranch, commit, push to YOUR fork, then open a PR to the original
git switch -c fix-typogit push -u origin fix-typogh pr create --repo owner/projectWhy: reviewing is half of working on GitHub. A good review checks that the change does what the PR says, is readable, and has tests — and says so kindly and specifically. Note: prefer questions and suggestions over commands; you are reviewing the code, not the person.
Review from the terminal, or use the PR's "Files changed" tab in the browser
gh pr checkout 42 # check it out and run it locally firstgh pr diff 42 # read the full diffLeave the verdict
gh pr review 42 --approvegh pr review 42 --request-changes --body "One question on error handling…"Why: branch protection rules stop anyone (including you) from pushing straight to main or merging a PR that has not been reviewed or has failing checks. On a team, this is what keeps main trustworthy. Note: this is configured once in the repo settings, not in code.
In the browser: repo → Settings → Branches → "Add branch ruleset" Common rules to enable for "main": - Require a pull request before merging - Require at least 1 approval - Require status checks (your CI) to pass - Block force pushes
After this, even you must open a PR — main can only change through review.