Merge vs. Squash Merge
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 maingit 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.
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 maingit 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
c from the
header branch are combined into one commit
b' on the
main branch. The commit message of the combined commit is
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.