What's changed: Expanded content (added diagrams)
3.1Issues, Pull Requests, and Review
Collaboration on GitHub revolves around Issues and Pull Requests (PRs).
■ Issues Issues track and discuss bugs, requests, and tasks one at a time. They integrate with Labels (classification), Assignees, Milestones (deadline/release groupings), and Projects (boards) to make work visible.
■ Pull Requests (see the diagram) PRs are central to collaboration: they propose merging a work branch (compare) into the default branch (base), merged after review and automated checks. Reviews are submitted in three states: • Approve = okay to merge. • Request changes = edits needed; can block merge until addressed. • Comment = feedback/questions without a verdict. A work-in-progress PR can be a Draft, switched to Ready for review when prepared. Merge methods are Create a merge commit, Squash and merge (compress commits into one), and Rebase and merge. Writing "Closes #123" in a PR auto-closes that issue on merge.
■ Protecting main Branch protection rules (or rulesets) enforce required reviews, required status checks (CI passing), conversation resolution, and linear history before merge, and can block direct pushes and force-pushes. Auto-merge merges once conditions pass; the merge queue validates multiple PRs against the post-merge state and integrates them serially. Use CODEOWNERS to auto-request reviewers when specific paths change. In review, "suggested changes" let a reviewer propose exact edits the author can apply in one click.
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Which merge method combines commits into one?
Q2. What enforces required review approval before merge?

