What is the difference between merge --squash and rebase?

Question

I'm trying to understand the difference between a squash and a rebase. As I understand it, one performs a squash when doing a rebase.

Answer 1

Merge commits: retains all of the commits in your branch and interleaves them with commits on the base branch

Merge Squash: retains the changes but omits the individual commits from history

Rebase: This moves the entire feature branch to begin on the tip of the master branch, effectively incorporating all of the new commits in master

More on here

---

The first two diagrams come from About pull request merges on the GitHub Docs

Answer 2

Both git merge --squash and git rebase --interactive can produce a "squashed" commit. But they serve different purposes.

• git merge --squash abranch

will produce a squashed commit on the destination branch, without marking any merge relationship. (Note: it does not produce a commit right away: you need an additional git commit -m "squash branch")

This is useful if you want to throw away the source branch completely, going from (schema taken from SO question):

git checkout stable

          X               stable
         /
a---b---c---d---e---f---g tmp

to:

git merge --squash tmp
git commit -m "squash tmp"


# In the following graph, G is c--d--e--f--g squashed together

          X-------------G stable
         /
a---b---c---d---e---f---g tmp

and then deleting tmp branch.

---

Note: git merge has a --commit option, but it cannot be used with --squash. It was never possible to use --commit and --squash together. Since Git 2.22.1 (Q3 2019), this incompatibility is made explicit:

See commit 1d14d0c (24 May 2019) by Vishal Verma (reloadbrain). ^{(Merged by Junio C Hamano -- gitster -- in commit 33f2790, 25 Jul 2019)}

merge: refuse --commit with --squash

Previously, when --squash was supplied, 'option_commit' was silently dropped. This could have been surprising to a user who tried to override the no-commit behavior of squash using --commit explicitly.

git/git builtin/merge.c#cmd_merge() now includes:

if (option_commit > 0)
    die(_("You cannot combine --squash with --commit."));

---

• git rebase --interactive

replays some or all of your commits on a new base, allowing you to squash (or more recently "fix up", see this SO question), going directly to:

git checkout tmp
git rebase -i stable

   stable
      X----------------G tmp
     /
a---b

If you choose to squash all commits of tmp (but, contrary to merge --squash, you can choose to replay some, and squashing others).

So the differences are:

• squash does not touch your source branch (tmp here) and creates a single commit where you want.
• rebase allows you to go on on the same source branch (still tmp) with:
  • a new base
  • a cleaner history

Answer 3

Let's start by the following example:

Now we have 3 options to merge changes of feature branch into master branch:

1. Merge commits
   Will keep all commits history of the feature branch and move them into the master branch
   Will add extra dummy commit.

2. Rebase and merge
   Will append all commits history of the feature branch in the front of the master branch
   Will NOT add extra dummy commit.

3. Squash and merge
   Will group all feature branch commits into one commit then append it in the front of the master branch
   Will add extra dummy commit.

You can find below how the master branch will look after each one of them.

In all cases:
We can safely DELETE the feature branch.

Answer 4

Merge squash merges a tree (a sequence of commits) into a single commit. That is, it squashes all changes made in n commits into a single commit.

Rebasing is re-basing, that is, choosing a new base (parent commit) for a tree. Maybe the mercurial term for this is more clear: they call it transplant because it's just that: picking a new ground (parent commit, root) for a tree.

When doing an interactive rebase, you're given the option to either squash, pick, edit or skip the commits you are going to rebase.

Hope that was clear!

Answer 5

The way I have learned to understand the value and difference between squash, merge, etc. is to put together this short tutorial for myself.

---

If you follow this it will explain everything you want to know about squash, merge as well as fast forward, and rebase.

---

Feature Branches

Say you have Main branch at the Origin, with a history of Commits, A.

You pull from Main, and create a new branch, FeatureA, such that you have commit history:

• A, B, C, F1, F2, F3 (three commits on FeatureA branch)

You want to push you changes into Origin and merge into Main. Since Main on Origin hasn’t changed you are also able to Fast Forward.

Merge with Fast Forward

Apply all the commit history of FeatureA branch on top of Main’s commit history.

Merge with Squash

An option available whenever your branch has multiple commits is to squash. Squashing combines the history of FeatureA branch into a single commit when merging with Main.

Fast forward isn’t possible if there have been other changes on Main.

If you made changes to the FeatureA branch, meanwhile others had pushed into Main, such that the Origin history of Commits is now: A, B, C

You want to push you changes into Main branch on Origin, and you have a few different options:

• Merge (without fast forward)
• Rebase,
• Stash and Pull.

Merge (aka. Merge without fast-forward)

If you were to fetch a local copy of Origin’s Main branch and merge it into your local FeatureA branch, you would create a commit for that merge, M. You local history on FeatureA would be: A, F1, F2, F3, M, where M is the merge commit.

You could then merge to Main (squashing if you wanted). Note that if you don’t squash, you will introduce a Merge commit into the Main commit history:

• A, B, C, F1, F2, M.

You could avoid this by squashing your branch when merging to Main, as described above in the Squash section, resulting in: A B C F, like so:

Rebase

Rebase is another option to avoid introducing a merge commit into the history. It essentially takes your changes, and makes it as if you had begun on the latest Main, rather than on an outdated version of Main. For example, after rebasing your Feature branch would branch off from A, B, C, (instead of A, as it was originally). The result:

• A, B, C, F1, F2, F3

• A, B, C, F (with squash)

Note, there is no Merge commit, M

The way Git achieves this is to systematically--commit-by-commit--apply the changes from origin’s Main to your branch. The end result is as if you had not started your FeatureA branch in the past based off commit A, but as if you started all your changes on top of the latest Main.

The problem is, in the way this is done. For each commit that has to be applied into your FeatureA branch, git checks for merge conflicts, and you have to resolve them. If there has been more than one change to Main on Origin since your FeatureA branch, you can be resolving merge conflicts over and over again.

Perhaps a stash and pull is easier?

Stash and Pull

Stash your FeatureA, Fetch/Pull an up to date local copy of Main from Origin, and either create a new branch and apply your stash. (Or merge your new Main branch into your branch, and apply your stash. If doing the latter, squash to avoid a merge in the commit history.) Then you can push to Origin / create pull request.

Answer 6

Merge and rebase both retain commit history vs squash doesn't. Retaining commit history has a huge impact and I learned it the hard way in the following scenario:

We have master, develop and feature branches. Feature is created off of develop and merged to master upon release. Hotfix branch was created off of master and merged (so develop doesn't know about it). Master was not merged back to develop after release so they got out of sync where merge from master back into develop shows changes and forward merge from develop to master also shows changes (even when nothing in develop has changed).

The cause of this was squashing commits when master is merged back to develop. Doing a regular merge which keeps the commit history, fixed the problem. Merge from develop to master doesn't show any changes now as expected.