As the title says, I am not really clear about the differences between a git merge --squash and a git merge --no-commit.
As far as I understand the help page for git merge, both commands would leave me in an updated working-tree, where it is still possible to edit and then to do a final commit (or multiple commits).
Could someone clarify the differences of those 2 options? When would I use one instead of the other?
git merge --no-commit
This is just like a normal merge but doesn't create a merge-commit. This commit will be a merge commit: when you look at the history, your commit will appear as a normal merge.
git merge --squash
This will merge the changes into your working tree without creating a merge commit. When you commit the merged changes, it will look like a new "normal" commit on your branch: without a merge commit in the history. It's almost like you did a cherry-pick on all the merged changes.
Basically, there's no such difference at the very end, however looking at the sketch here below, once you checkout master branch
A---B---C topic
/ \
D---E---F---G---H master (from the documentation https://git-scm.com/docs/git-merge)
git merge topic : incorporates/replay changes from the named branch (since its history diverged from the current branch) into the current branch and record the result in a new commit H along with the names of the two parent commits and a log message from the user describing the changes. Then it's up to you to push it upstream, as usual.$ git log --all --decorate --oneline --graph
* 72e576d (HEAD -> master) H Merge branch 'topic'
|\
| * dda0d97 (topic) C
| * 3471c39 B
| * cfb8410 A
* | a1c7e23 G
* | 5c0b97b F
|/
* c463d89 E
* 2312a5b D
$ git show HEAD -m
commit 72e576d (from a1c7e23) (HEAD -> master)
Merge: a1c7e23 dda0d97
H Merge branch 'topic'
diff --git a/A b/A
diff --git a/B b/B
diff --git a/C b/C
commit 72e576d (from dda0d97) (HEAD -> master)
Merge: a1c7e23 dda0d97
H Merge branch 'topic'
diff --git a/F b/F
diff --git a/G b/G
git merge --no-commit : the same as above, but stop just before creating a new commit, to give the user a chance to inspect and further tweak the merge result before committing. Then it's up to you to commit what has been added to the index and push it upstream, as usual.$ git log --all --decorate --oneline --graph
* f576f37 (HEAD -> master) H
|\
| * dda0d97 (topic) C
| * 3471c39 B
| * cfb8410 A
* | a1c7e23 G
* | 5c0b97b F
|/
* c463d89 E
* 2312a5b D
$ git show HEAD -m
commit f576f37 (from a1c7e23 ) (HEAD -> master)
Merge: a1c7e23 dda0d97
H
diff --git a/A b/A
diff --git a/B b/B
diff --git a/C b/C
commit f576f37 (from dda0d97) (HEAD -> master)
Merge: a1c7e23 dda0d97
H
diff --git a/F b/F
diff --git a/G b/G
git merge --squash : working tree and index state are as if a real merge happened (except for the merge information), without committing it, thus allowing to create a single commit on top of the current branch. Again, it's up to you to commit and push upstream, as before.$ git log --all --decorate --oneline --graph
* 118019a (HEAD -> master) H
* a1c7e23 G
* 5c0b97b F
| * dda0d97 (topic) C
| * 3471c39 B
| * cfb8410 A
|/
* c463d89 E
* 2312a5b D
$ git show HEAD -m
commit 118019a (HEAD -> master)
H
diff --git a/A b/A
diff --git a/B b/B
diff --git a/C b/C
NOTE: fast-forward updates do not create a merge commit, thus, to ensure your branch is not changed/updated use --no-ff with --no-commit option.
The difference between git merge --no-commit and git merge --squash is that in the second case the next commit will have a single parent commit.
For example, in this situation
the commands
git merge dev --no-commit
git commit -m "msg"
or simply git merge dev -m "msg" will produce
On the other hand
git merge dev --squash
git commit -m "msg"
gives you
The commits E and E' will give you the exact same working directory. The difference is in their number of parents.
(Personally, I wouldn't have called this operation "squashing".)
