Git & GitHub Fundamentals · Module 09 of 12

Forks, pull requests and reviews

Understand GitHub collaboration: feature branches, forks, pull requests, review evidence and protected integration paths.

Learning objectives

By the end of this module, you should be able to:

Distinguish a branch from a fork.
Explain base and head branches in a pull request.
Use review and repository rules to protect important branches.

Branch or fork?

A branch is another reference inside a repository. A fork is a separate GitHub repository connected to an upstream repository network. Teams with write access often use branches; external contributors commonly use forks.

A pull request is a review proposal

A pull request compares changes from a head branch against a base branch. Discussion, checks and reviews happen before a merge decision. The Git commits remain the underlying source history.

Protect the integration path

GitHub protected branches and rulesets can restrict direct pushes or force pushes and can require reviews or status checks. Exact repository policy is organization-specific; do not assume admins or bypass actors have the same restrictions as ordinary contributors.

Worked examples

See the idea in practice.

Review what a pull request would contain

git log main..feature/review --oneline
git diff main...feature/review
git diff --check main...feature/review

main...feature shows changes since the merge base.
diff --check can catch whitespace errors before review.

Hands-on lab

Lab — Simulate a pull-request review locally

Goal: Create a feature branch, inspect its review diff and integrate only after checks.

Before you start

Git 2.23 or newer is recommended so the labs can use git switch and git restore.
Run labs in a disposable working directory; the included validator creates and removes its own temporary repository.

STEP 1

Create repository

mkdir -p ~/gnu-git-labs/module09 && cd ~/gnu-git-labs/module09
git init -b main
git config user.name "GNU Learner"
git config user.email "learner@example.invalid"
printf "# Service\n" > README.md
git add README.md && git commit -m "Create service readme"

STEP 2

Create proposed change

git switch -c feature/review
printf "\nRun on port 8080.\n" >> README.md
git commit -am "Document service port"

STEP 3

Review from main perspective

git switch main
git log main..feature/review --oneline
git diff main...feature/review
git diff --check main...feature/review

STEP 4

Integrate after review

git merge --no-ff feature/review -m "Merge reviewed documentation change"

Verify

The review diff contains only the feature change.
diff --check succeeds.
main contains the reviewed commit after merge.

Expected outcome

The local workflow mirrors the evidence a GitHub pull request exposes, while GitHub adds conversation, permissions and checks.

If it fails

If main...feature fails, confirm both names exist.
A clean diff does not replace tests; run repository-specific validation too.

Real-world connection

Pull requests create an auditable integration point for code review, automated checks and ownership policies.

Avoid these traps

Common mistakes

Treating a pull request as a replacement for Git history.
Merging without reading the actual diff.
Assuming a fork and a branch are the same object.

Knowledge check

Can you explain it without looking back?

Open each answer only after you have tried to answer the question yourself.

1What are the two sides of a pull request comparison commonly called?

The base branch receives changes; the head branch proposes them.

2What is a fork?

A separate GitHub repository connected to an upstream repository network.

3Why protect main?

To enforce the repository’s review/check/change-control policy before integration.