Merging a Pull Request
Topic 36

Merging a Pull Request

Collaboration

Approved. Merging puts the branch's commits into main — and GitHub performs exactly the merge you learned in Chapter 6, on its own copy of the repository.

Two things follow immediately, and both are commonly forgotten. The branch should be deleted, and your laptop does not yet know any of this happened.

Pressing merge

The button merges the branch into main on GitHub's side. The pull request closes and keeps everything attached to it: the description, every comment, every commit, and the record of who approved it.

That archive is quietly valuable. A year later, "why does the meeting time live in one place instead of two" is answerable by finding the pull request, and the answer is a conversation rather than a guess.

The three buttons

GitHub offers three ways to merge, and teams pick one and stay consistent.

Create a merge commit — the default, reached by the button labelled Merge pull request — is the Chapter 6 behaviour: your commits go into main as they are, plus a merge commit recording the join. It is this book's default and the most honest about what happened.

Squash and merge flattens every commit on the branch into one. The history becomes one entry per pull request, which some teams much prefer — at the cost of losing the individual steps.

Rebase and merge replays your commits onto main for a straight-line history. It is the thing this book does not teach, and you can recognize the button without using it.

None is correct in the abstract. Find out which one your project uses and follow it.

Deleting the branch

GitHub offers a button for this right after the merge. Take it. The commits are in main, so the label has done its job — exactly the argument from Chapter 6, with the same reasoning.

Bringing it home

This is the step people forget, and forgetting it causes tomorrow's confusion:

Catch up, and tidy your own copy
git switch main
git pull
git branch -d fix-meeting-time

The merge happened on GitHub's copy. Your local main is now behind, and until you pull it, everything you do starts from an outdated version of the project. GitHub's branch deletion also did nothing to your local label, which is why the third command is there.

After the merge, before the pull — the two copies disagree
GitHub — after pressing merge
mainhas the merge
fix-meeting-timedeleted
Your laptop — until you pull
mainout of date
fix-meeting-timestill present

When merging is blocked

Sometimes GitHub says the branch cannot be merged automatically. That means main moved while you were working, and the two changes overlap — the Chapter 6 conflict, arriving through a website.

Fix it locally, where you have your editor and the abort command:

Update your branch, resolve, push
git switch fix-meeting-time
git pull origin main
# resolve the conflict exactly as in Chapter 6, then:
git add index.html
git commit
git push

The pull request updates itself and the block clears. Same conflict, same markers, same resolution — one extra step at the start to bring main's changes into your branch.

Common Confusions
  • "Merging on GitHub updates my computer." It updates GitHub's copy. git pull brings it home, and forgetting that is the most common cause of a confusing rejection the next day.
  • "Deleting the branch on GitHub deletes it locally." Two copies, two labels. git branch -d handles yours.
  • "Squash is tidier, so it is better." It trades commit-by-commit history for one entry per pull request. That is a team preference with real costs on both sides, not a rule.
  • "A blocked merge means the pull request has to be recreated." It means main moved. Update your branch, resolve the overlap, push — the same pull request clears.
Why It Matters
  • The pull-after-merge step keeps your local main honest, and skipping it is what produces the mysterious conflicts of week three.
  • Seeing GitHub perform the Chapter 6 merge confirms that nothing new was learned here: the website is a convenience over commands you already know.
  • Knowing which of the three buttons your team uses is the kind of small local convention that makes you look like you have done this before.

Knowledge Check

You press merge on GitHub. What is the state of your laptop?

  • Unchanged, so your local main is now behind until you pull
  • Updated automatically, because the two copies stay synchronized
  • Updated for main but not for the branch, which stays as it was
  • Locked until you pull, so no further commits can be made locally

What are the two cleanup steps after a pull request merges?

  • Pull main to bring the merge home, then delete your local branch label
  • Delete the branch on GitHub, and push main back to the remote
  • Revert the merge commit, then re-merge locally to keep the copies matching
  • Clone the repository again, so the local copy matches GitHub exactly

GitHub says your pull request cannot be merged automatically. What has happened?

  • main moved while you were working, and the two changes now overlap
  • Your branch has too many commits and needs to be squashed before merging
  • The reviewer has not approved yet, so merging is blocked by the settings
  • The remote copy of your branch is out of date and needs pushing again

Which merge button matches what Chapter 6 taught?

  • Create a merge commit, which keeps your commits and records the join
  • Squash and merge, because it produces one clean commit per change
  • Rebase and merge, because it produces the simplest possible history
  • Any of them, since all three produce exactly the same history in the end

You got correct