git中merge还是rebase？git之圣战merge vs rebase

merge 和 rebase的区别？

merge 是合并的意思，rebase是复位基底的意思。

现在我们有这样的两个分支,test和master，提交如下：

     D---E test
    /
A---B---C---F master

在master执行git merge test然后会得到如下结果：

     D--------E
    /          \
A---B---C---F---G    test , master

在master执行git rebase test,然后得到如下结果：

 A---C---D---E---C `---F` test , master

可以看到

• merge操作会生成一个新的节点，之前提交分开显示。

• 保留了每个分支上的完整提交历史和分支信息。

• 比较适合用于多人协作或需要更明确分支结构的情况。

• rebase操作不会生成新的节点，是将两个分支融合成一个线性的操作。

• 保持提交历史简洁和线性，更容易追踪和理解。

• 可以合并多个提交为一个更有意义的提交。

• 可以减少合并冲突的可能性。

想要更好的提交树，使用rebase操作会更好一点，这样可以线性的看到每一次提交，并且没有增加提交节点——时间线更漂亮，符号强迫症和整洁癖的喜好！但是，它对 安全性 (safety) 和 可追溯性 (traceability) 做了折衷：

为了做到这个，的所有 commit 都被重建了，它们的 hash 已经不是原来的那个了！所以，代码变得难以追溯历史，比如上面的 feature 分支在 rebase 之后，无法知道是什么时候从 main 切出进行的修改。无法知道什么时候合入的 main 分支。

所以，永远不要在公共分支上使用 rebase !!

如果你和同事公用了一个 feature 分支，而你使用 rebase 同步主干。很有可能弄丢同事的代码！

在操作中

• merge操作遇到冲突时候，当前merge不能继续下去。手动修改冲突内容后，add 修改，commit 就可以了

• 而rebase操作的话，会中断rebase，同时会提示去解决冲突。解决冲突后，将修改add后执行git rebase -continue继续操作，或者git rebase -skip忽略冲突。

Merge和Rebase的缺点

Merge的缺点：

• 合并后的提交历史可能会变得复杂。

• 可能会造成一些无用的合并提交。

Rebase的缺点：

• 修改提交历史可能引发其他开发者的困惑。
  

• 可能会造成分支变动，需要额外的注意和协作。

• 难以追溯历史，比如上面的 feature 分支在 rebase 之后，无法知道是什么时候从 main 切出进行的修改。无法知道什么时候合入的 main 分支。
  

merge 和 rebase如何选？

程序员间的圣战蛮多：

比如tab 还是2个空格（支持tab，省事）

比如可以省略分号 要不要加上？（支持加上，因为分号加上又不要手动，IDE自动干了，有可以增加代码的可读性）

比如 git merge vs rebase，这个个人没有一边倒，但是还是支持merge多一点。在此问题上，觉得轮子哥的这句话特别有道理：

"git rebase就是那种典型的，使用MVC模型的时候喜欢想着用Model来代替View的这种人，会喜欢做的事情。其实也没有什么好和不好，但是保留原始数据显然是相当重要的。你嫌图形不好看的话，自己写一个程序去画就好了。就像没有人会在SQLServer里面真的用一棵树来表示树形的留言一样。你觉得commit太乱看起来不舒服的话，就去改输出commit的程序，不要改数据本身的意思"

rebase，合并的结果好看，一条线，但合并过程中出现冲突的话，比较麻烦

• rebase过程中，一个commit出现冲突，下一个commit也极有可能出现冲突，一次rebase可能要解决多次冲突；

• 合并的历史脉络（冲突）被物理消灭了

• merge，合并结果不好看，一堆线交错，但合并有冲突的话，只要解一次就行了；

有人说："团队里有新人且水平参差不齐的情况下，建议统一 git merge，不然容易出来麻花，过去解完麻花再传授一番 git rebase 的原理然后 git push -f 一发又有什么收益呢"。

这里再次感谢WasteOfTime的回答："为了追求Git的线好看，在团队合作中使用rebase说轻点是舍本逐末，说重了是对团队不负责任。个人以及本地项目无所谓。"

但是从中国特色的敏捷开发情况（疯狂改方案，迭代），

”如果只在本地修改一两个commit，然后马上提交到master，跑完所有unit test，integration test，regression test等，直接发布，也就是continuous integration的理想状态，那么rebase是极好的，保证了master的线性和万一出事了可以准确的revert“——Eason的回答——其实意思就是：

如果经常需要rollback回滚就用rebase

个人觉得的最佳方案是：

总结就是：

• 合代码到公共分支的时候使用git merge（develop分支向master分支合并开发的内容），书写正确规范的merge commits留下记录。

• 合代码到个人分支的时候使用git rebase（develop分支拉取master分支的最新改动），可以不污染分支的历史提交记录，形成简洁的线性记录。

• 不过需要尽量及时rebase上游分支，发现有冲突，merge。

多人协作分支，同步主干，请使用 merge !!——避免破坏其他人的历史记录。

最后给坚持全部rebase的同行，送大家一篇助长记忆经文（rebase丢失的数据）

虚空藏菩萨咒（资料图）

虚空藏菩萨咒为般若结晶，能增智光，能助大定，加强记忆力，促进心通。如能勤读此咒，易得一心不乱、忆持不忘之力。

咒语原文：

南无虚空藏菩萨摩诃萨（三称）

阿袮，逻阇鞞。钤浮娑阇鞞。

耶婆奈阇鞞。博厕，娑迷。

波咤逻阇鞞。他奈婆逻鞞。

萨多逻伽逻泥。休磨休磨。

摩诃，伽楼尼迦。娑婆诃。

虚空藏咒注音：

ā nǐ，luó shé pí。qián fú suō shé pí。

yē pó nài shé pí。bó cè，suō mí。

bō zhà luó shé pí。tuō nài pó luó pí。

sà duō luó qié luó ní。xiū mó xiū mó。

mó hē，qié lóu ní jiā。suō pó hē。

发音注解：

阿(ā啊)袮(nǐ你)：祢：读作(nǐ你)属于古音，而今音为(mí迷)。

阇：读作(shé蛇)，有的方音读“萨”。

鞞：发音(pí皮)，还有其它三种读法：(pí皮)、(bǐ比)、(bǐng丙)。这里念(pí皮)比较合适。因鞞通毗，“鞞杀社”，也译成“毗煞社”;“阿鞞跋致”，也译成“阿毗跋致”；“鞞嚧社那”，也译成“毗卢舍那”。（见《佛学大辞典》。）

耶：读(yē噎)。另读(yě也)

厕：读作(cè测)，有的方音读“次”。

咤：读音(zhà乍)，不读今音(zhā)。

伽：读(qié茄)，有的地方读“斜”。

磨：读作(mó模)，有的方音读成“我”。

诃：读音为(hē呵)，有的方音读“呼”。

迦：读(jiā加)。

转载本站文章《git中merge还是rebase？git之圣战merge vs rebase》,
请注明出处：https://www.zhoulujun.cn/html/tools/VCS/git/5838.html