Review code and choose a merge method

Merging is not just pressing a green button. A team should understand what review evidence it needs and what history shape its chosen merge method creates.

GitHub reviews can approve, comment or request changes. Review comments should point to concrete behavior, correctness, maintainability, tests or documentation—not just personal style preferences.

GitHub can support different merge methods depending on repository settings: a merge commit preserves branch integration, squash merge condenses the PR into one commit on the base branch, and rebase merge adds commits linearly without a merge commit. Teams should pick a policy that matches how they want history to be read and reverted.

Run this in a disposable practice repository unless the lesson explicitly says otherwise.

# Useful local review before approving
git fetch origin
git diff origin/main...origin/feature/search

# GitHub CLI example
gh pr view --web

The three-dot diff is commonly useful for seeing changes introduced on the feature side relative to the merge base. GitHub's Files changed tab provides an interactive review surface.

Your task: For a PR with 12 tiny fixup commits, compare the consequences of merge commit, squash merge and rebase merge. Choose one and justify the trade-off.

Approval does not prove correctness. Automated tests can miss cases, and reviewers can miss issues. Treat review and CI as complementary evidence.

Review code and choose a merge method is complete when you can explain the state being changed before you run the command, not merely repeat the syntax.

Read further: official supporting documentation.