V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
bandian
V2EX  ›  问与答

git rebase 与 merge 到底有什么区别

  •  
  •   bandian · 2021-06-19 12:05:18 +08:00 · 1569 次点击
    这是一个创建于 1013 天前的主题,其中的信息可能已经有所发展或是发生改变。

    看了一下网上的答案五花八门的,我自己的理解是如果两个分支不存在冲突,那 merge 与 rebase 没有任何区别,都是按照时间顺序把提交的内容插到当前分支。

    如果存在冲突,merge 会把没有冲突的节点先按时间顺序插到当前分支,再把所有出现冲突的节点后的所有提交打包,这个时候你只需要解决一次冲突,然后 git 会生成一个 merge request 的总的提交信息。

    而 rebase 则是完全按照时间顺序插入到当前分支,每个出现冲突的提交都需要单独解决。

    AoEiuV020
        1
    AoEiuV020  
       2021-06-19 12:15:04 +08:00 via Android
    rebase 相当于新的提交,放弃了原来的提交,hash 变了,不再是原来那个提交了,
    bandian
        2
    bandian  
    OP
       2021-06-19 12:21:29 +08:00
    @AoEiuV020 看了一下,确实是,从 rebase 的第一个插入的提交开始,当前分支上所有提交的 hash 都改变了
    HarryQu
        3
    HarryQu  
       2021-06-19 14:51:06 +08:00   ❤️ 4
    wr516516
        4
    wr516516  
       2021-06-19 15:22:46 +08:00
    @HarryQu 这个网站太好用了 我一会 rebase 用的都不是很熟练
    msg7086
        5
    msg7086  
       2021-06-19 15:49:18 +08:00   ❤️ 6
    merge 会产生一个新的 merge 节点。
    一般个人项目可以一路 rebase,稍微大一点点的可以按照 feature 来 merge,大公司的话可以考虑 squash merge 。

    然后最主要是要分清操作的方向。
    比如说你有一个主线 dev 分支,然后有各种 feature 分支。
    把更改从 dev 搬到 feature 一般用 rebase,把更改从 feature 合并进主线一般用 merge 。
    因为一般用 rebase,所以 conflict 应该在 rebase 的时候解决。
    用 merge 解决 conflict 是很坏的习惯,因为一般习惯是 merge 本身不包含改动,只包含合并。
    如果你在 merge 里偷偷藏了改动的话,需要 revert 或者 blame 或者 cherry pick 的时候就容易漏掉改动。
    zoffy
        6
    zoffy  
       2021-06-19 16:35:47 +08:00
    @msg7086 #5 老哥稳,相当明白。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5451 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 37ms · UTC 08:37 · PVG 16:37 · LAX 01:37 · JFK 04:37
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.