看过git merge，如果是fast-forward的情况，结果是非常令人满意的。但是在 non fast-forward的情况下，合并后的分支是按照我们在两个分支上提交记录的时候顺序显示的，而且会多出一个合并分支的提交记录。而使用--squash进行的提交，最后得到的提交记录，会将我们在要合并的分支上所作的多次修改合为一条做一次新的提交。
其实，我们可能希望的是，当我们合并feature时，将f1,f2作为新的提交记录在m3的后面，同时保留f1和f2的提交记录。
git rebase : 变基
在feature分支上进行git rebase，因为我想要改变提交起点的分支是feature，我们希望feature不再是从m2开始修改，而是从m3开始修改。因为如果feature是从m3开始修改的，那使用git merge的时候就符合了fast-forward的条件。
先看一下当前feature分支的提交记录：
执行命令:
git rebase master
此时在feature分支上的记录就和我们预期的一致，只是需要注意的是，现在的f2和f1的提交信息虽然和以前一样，但实际它们的commitID已经改掉了，也就是这其实是两次新的提交。
所以rebase在多人共同开发的时候要慎重使用，因为你更改了这个分支的所有记录的commitID，重写了历史记录，此时如果有其他开发者在这个分支上开发就会有问题。
结合rebase和merge,完成fast-forward
git checkout master
git merge feature
git cherry-pick
如果我们并不想合并整个分支过来，而只是想合并某个分支的某次提交，可以使用cherry-pick命令，这个命令会在当前分支上创建一个new commit，生成新的commitID。
git cherry-pick commitID
比如当前在master分支上，但在feature分支的一次提交上修改了一个master上的bug，但feature中还有其他功能没有开发完，目前还不能整个合并到master分支。所以我们可以在master分支上使用cherry-pick命令，将特定的提交复制到master上。
确实是复制，因为内容虽然一样，但是根据commitID，其实是一次新的提交。
最后，当我们开发好feature分支的内容，在master分支合并feature后，会发现有两条内容一样的提交，这可能是一个缺陷吧~
