If you're familiar with working on branches you probably know the git merge command already. With this command, you can incorporate commits from one branch into another.

For example, if we wanted to have the commits from the header branch in our main branch we could run the following commands.

Note: Don't run the commands on your machine since the branch is already merged.

git checkout main
git merge header

This is what the commit history in our case would look like before and after the merge.

Before the merge, we only have the "Initial commit" on the main branch and two additional commits "Add header markup" and "Add header styles" on header. The two commits on the header branch are the ones you added.

After the merge, the two commits from the header branch have been copied on to the main branch. Both branches now contain the exact same commits.

Note: we might have an additional merge commit in case of conflicts between the branches.

By default, GitHub does a merge as described above. But not in our case.

You may have realized already that the button in the PR didn't just say Merge but rather Squash and merge.

Squash Merge

Many professional teams use a different setup for their GitHub repositories. They require a linear history which means that they don't allow merge commits in the main branch.

One option to prevent merge commits to appear is to run the git merge command with the squash option. This is what happened when you clicked the green button.

Note: Don't run the commands on your machine since the branch is already merged. This is to illustrate what GitHub does behind the scenes.

git checkout main
git merge --squash header

Now, what does it mean to run git merge --squash?

It means that all the commits from the header branch are combined (or squashed) into a single commit and then added to the main branch. This is what it looks like visually.

Here you can see that the commits b and c from the header branch are combined into one commit b' on the main branch. The commit message of the combined commit is Header (#1).

That's the title that was suggested by GitHub when you merged the PR. Here the screenshot again as a reminder.

The advantage of squash merging

In a typical team environment with code reviews, you often see small commits with messages like fix xyz or update according to code review. These are not great commit messages. But realistically, that's what you encounter often.

The advantage of squash merging is that you don't have these commits in your main branch. Instead you have only one commit per Pull Request or feature. This makes it a lot easier to reason about the commit history later on and attribute changes to tasks.

See for yourself

If you want to see the history on your local machine for yourself run the git log command on both branches. I like to use the oneline option to have a more concise output.

git log --oneline header

The commit history on my header branch looks like this

Now check out the main branch and run the git log command there again. You should see something like this.

That's exactly what we saw in the squash merge diagram above.

Great, after this piece of theory let's get our hands dirty again and start the next task: the footer.

Next: Planning