【备份】搞清：merge、–no-ff选项、merge –squash、rebase、cherry-pick

参考：

https://backlog.com/git-tutorial/cn/stepup/stepup1_4.html

https://segmentfault.com/a/1190000021127603

仅做个人笔记

---

 

 

 

目录

【git merge test】(包含–no-ff选项)

【git merge --squash test】

【git rebase test】

​【git cherry-pick】

【总结】

---

【git merge test】(包含–no-ff选项)

当master在分支后被更改过，合并就会多一次提交(E)。

当master在分支后没有被更改过，两条线就会并起来，此被称之为【fast-forward】（快进）合并。

但是【fast-forward】这样对以后的回退什么的操作并不友好，就是因为少了一个类似于上面(E)这样的提交。所以使用--no-ff(non fast-forward)选项来避免这样，【git merge --no-ff test】会强制生成一个合并提交点。

【git merge --squash test】

他不会把分支上的提交记录也放到master分支上。内部与[在master分支上执行git pull branch]效果一致。

会把brantch的所有改动都放在master中但是并不会提交，本地会显示有东西未add需要手动commit，但是因为手动add，commit后在brantch的所有修改记录的修改人都会变成你自己。在提交记录上只会有一个提交记录。

不足是会变更提交人为自己，对以后的查询不是很方便。

【git rebase test】

作用：

(1)删减提交哪些次提交：

当执行了git rebase -i master_0命令后会出现一个编辑命令页面：

 

其中红框是brantch_0所有提交记录，要变基到哪个分支。
图中有解释pick, squash, fixup命令的含义。把不需要的提交记录使用squash和fixup进行修改，然后wq保存修改。此时查看brantch_0分支的提交记录会发现不要的提交记录已经合并。
然后再进行merge。

其中（H）是合并的merge记录。
运行git rebase --continue命令继续变基。
运行git rebase --abort命令回到rebase之前的状态。

(2)变基。不会像merge那样使提交记录变得繁杂，他会是一条线。下面的对比：

场景：

merge后：

rebase后：

【git cherry-pick】

把某分支的某次提交merge过来，其合入的不是某个分支而是某次提交。

【总结】

（首先，merge、–no-ff选项、merge –squash只区别去提交记录的不同。rebase只区别于可以增删提交。cherry-pick只区别于可以合并提交。都不对merge代码的方式做改变，merge代码的方式唯一。）

当你要【git merge test】时那就用【git merge –no-ff test】。
当你要把分支提交记录提炼时就使用【git merge –squash test】或【git rebase test】，后者不会变更提交人，且变基，且可以增删某些次提交。
当你要把某分支的某次提交合到当前分支时，那就【git cherry-pick】吧~