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?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.

