问题
If I work in a standard master-feature workflow, what'd be the difference between squashing a feature branch into master and cherry-picking it into master?
Example branches:
m1 -- m2 master
\-- f1 -- f2 feature
I think both have the same output ie
m1 -- m2 -- -- -- m3 master
\-- f1 -- f2 feature
回答1:
There are two important differences between merge --squash and cherry-pick:
1. Cherry-picking only moves one commit
That is, if you have a the situation you described above and you (on master) do a git cherry-pick feature, the resulting branch will look like this:
m1 -- m2 -- f2’ master
\-- f1 -- f2 feature
This means the changes from f1 are not present on master (and cherry-picking possibly fails if f2 depends on them.
2. Cherry-picking creates a commit
merge --squash does not immediately commit, instead it creates a summary of all the changes and makes them ready to commit. This is essentially a patch of your complete branch changes, the same that git diff m1..feature would show.
On my machine, a quick test gave this output:
$ test git:(master) git merge --squash testbranch
Squash commit -- not updating HEAD
Automatic merge went well; stopped before committing as requested
The important bit here is the "not updating HEAD", which is git-speak for "I didn’t commit the stuff I did". The second sentence in fact is far more user-friendly…
This feature is handy if you like to develop step-by-step (by committing all the little steps that led to the solution, e.g. with a commit after every successful test run. In this case, your history would likely get cluttered with hundreds of one-liner commits. So it is probably better to do a merge-squash-commit every now and then (e.g. after you have developed one bit of the functionality).
来源：https://stackoverflow.com/questions/28189707/whats-the-difference-between-git-merge-squash-and-git-cherry-pick