GitHub Foundations #5 Domain 3-2: Collaboration — Pull Requests, Code Review, and Discussions

This is the second half of the collaboration domain. Where the first half was about work tracking centered on Issues, this post covers the central procedure of GitHub collaboration — the Pull Request and code review — plus Discussions, which the exam frequently contrasts with Issues. GitHub Pages and Wikis, which fall into the same domain, are covered as well. This post focuses on the precise meaning of each feature and state as the exam asks it. The practical side of running PRs well in a team is covered separately in Practical Git Workflows #5: Running Pull Requests — Review Size, Commit Messages, and Draft PRs.

The Pull Request lifecycle #

A Pull Request is a request to merge a branch’s changes into another branch, and at the same time the conversation space where those changes are reviewed. For the exam, know each stage of the lifecycle precisely.

1. Create — after pushing a branch, a Compare & pull request button appears on the repository page. base is the branch receiving the changes; compare is the branch sending them.
2. Draft — a PR that is not ready for review can be opened as a draft. In the draft state the merge button is disabled, and you must click Ready for review to enter the formal review stage.
3. Review — reviewers leave comments and either approve or request changes.
4. Merge — the changes land on the base branch through one of three methods.
5. Clean up — the merged branch is removed with the Delete branch button.

While a PR is open, any commits pushed to the same branch are reflected in the PR automatically. Two frequently tested points: there is no need to close and reopen the PR, and merging is blocked while the PR is a draft.

Code review — reviewers, CODEOWNERS, and the three review states #

Reviewers are assigned directly in the PR’s Reviewers field. To assign them automatically at the repository level, use a CODEOWNERS file.

# path pattern       owners
*.js                @frontend-team
/docs/              @octocat
/infra/             @org/platform-team

CODEOWNERS declares code owners per path pattern; when a PR touches a matching path, the owners are requested as reviewers automatically. An exam point: the file is allowed in exactly three locations — the repository root, docs/, or .github/.

When submitting a review, you choose one of three states.

In comments attached to specific lines, the suggested changes feature lets a reviewer propose a fix as a code block. The author reviews the suggestion and applies it as a commit instantly with the Commit suggestion button — a way to finish small fixes like typos without a round trip.

Linking PRs and Issues #

There are two ways to record which Issue a PR resolves.

• Write a closing keyword (closes #12 and so on) in the PR body. As covered in the previous post, the Issue closes automatically when the PR is merged into the default branch.
• Link manually through the Development field in the PR or Issue sidebar. The effect is the same as a closing keyword.

The linked Issue appears in the PR sidebar, and the Issue side shows which PR is in progress.

Discussions — how they differ from Issues #

Discussions is a forum-style conversation space attached to a repository. The exam frequently asks how it differs from Issues in purpose.

Discussions has categories such as Q&A, Ideas, Announcements, and Show and tell. In the Q&A category, the asker can pick one reply with Mark as answer. In the Announcements category, only people with maintain permissions can create new posts. When a conversation matures into concrete work, there is also a feature to convert a Discussion into an Issue. In short: work to track goes to Issues, open-ended conversation goes to Discussions.

GitHub Pages — from repository to static site #

GitHub Pages hosts a repository’s files as a static website. It is an exam point included in the collaboration domain.

• Site types — a user or organization site is created from a repository named username.github.io and served at that same address. A project site is created from any repository and served under the username.github.io/repository path.
• Publishing source — either publish directly from a chosen branch and directory (the root or /docs), or build and publish with a GitHub Actions workflow. The Jekyll static site generator is supported out of the box.
• Visibility — available on the free plan for public repositories; Pages for private repositories requires a paid plan.

Wikis — a documentation space attached to the repository #

A Wiki is a simple documentation space attached to a repository, used for manuals and design notes kept apart from the code. Each page is written in Markdown, and the Wiki itself can be cloned as a separate Git repository. The judgment the exam expects is modest: if you want documentation reviewed through the same PR flow as code, a docs/ directory inside the repository serves better than a Wiki.

The three merge methods, revisited #

The three methods behind the merge button were covered in the Git track, but here they are once more from the exam’s point of view.

• Merge commit — creates a merge commit, joining the two histories while preserving both.
• Squash and merge — combines all the PR’s commits into one and adds it to base. One PR becomes one commit.
• Rebase and merge — reapplies the PR’s commits onto base in order, without a merge commit.

Also remember that repository settings can restrict which of the three methods are allowed.

Wrapping up #

That completes the two collaboration posts. The PR lifecycle and the effect of drafts, CODEOWNERS and the review states, the Issues versus Discussions split, and the two publishing sources of Pages are the core of this post.

In the next post, “GitHub Foundations #6 Domain 4: Modern Development — Actions, Codespaces, Copilot, and Packages”, we cover the features that extend GitHub into a development platform. The difference between github.dev and Codespaces is an exam regular, so we will pin it down precisely in a table.