I am trying to understand the differences between git merge --squash <branch> and git rebase [--interactive] <base>.
Depending on the command, I am not sure what new commits appear on the current branch, if the original commits in <branch> are rewritten or left intact, and whether Git records a merge relationship.
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
Both git merge --squash and git rebase --interactive can produce a "squashed" commit. But they serve different purposes.
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 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--commitwith--squash
Previously, when
--squashwas 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--commitexplicitly.
git/git builtin/merge.c#cmd_merge() now includes:
if (option_commit > 0) die(_("You cannot combine --squash with --commit.")); 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: 
G is c--d--e--f--g squashed together?
tmp commits squashed together.G won't represent the same content than g, because of changes introduced by X.
git merge --no-ff temp instead of git merge --squash temp, then you get a messier history, but you can also do things like git revert e, much more easily. It's a messy, but honest and pragmatic history, and the main branch still remains fairly clean.git bisect or git blame when used too often (as in git pull --no-ff: stackoverflow.com/questions/12798767/…). There isn't one approach anyway, which is why this article described three (stackoverflow.com/questions/9107861/…)Let's start by the following example:
Now we have 3 options to merge changes of feature branch into master branch:
Merge commits
Will keep all commits history of the feature branch and move them into the master branch
Will add extra dummy commit.
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.
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.
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!
The way I have learned to understand the value and difference between squash, merge, etc. is to put together this short tutorial for myself.
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:
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.
Apply all the commit history of FeatureA branch on top of Main’s commit history.
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:
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:
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 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:
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 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.
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.
