git pull --rebase有什么优势 ?

淡定
  • 57

希望可以用具体例子说明, 已经知道怎么用了, 但确实还看不出优势

回复
阅读 701
4 个回答

约定使用 git pull --rebase 的团队,通常追求如下风格的 git commit history。

而不用的 git pull --rebase 的团队,往往追求的是如下风格

于我而言,我是使用 git pull --rebase 的,因为这种风格的 history 对我这种脑子笨的人来说更容易看明白

你是要问git merge和git rebase之间的区别吧?

一般情况下-你在master分支上完成了一些工作,并且从origin分支中拉了过来.提取后,情况如下:

  • o - o - o - H - A - B - C (master)

             \
              P - Q - R (origin/master)

    如果此时合并(git pull的默认行为),则假设没有任何冲突,您将得到以下结果:

  • o - o - o - H - A - B - C - X (master)

             \             /
              P - Q - R --- (origin/master)

    另一方面,如果您进行了适当的变基,则最终结果是:

  • o - o - o - H - P - Q - R - A' - B' - C' (master)

                        |
                        (origin/master)

    在两种情况下,工作树的内容都应该相同.你刚刚创建了一条不同的历史记录.将重写你的历史记录,就像你是在原始的新主分支(R)上提交,而不是最初提交的位置(H)一样.如果其他人已经从你的master分支中撤出了,则永远不要使用rebase方法.

实际上可以通过将config参数branch.<name>.rebase设置为true来为给定分支设置git pull使用rebase而不是合并.您也可以使用git pull --rebase一次拉动.

答案参考了这个博客:https://www.itbaoku.cn/post/2...

工作中的例子的话
rebase 会使 master 分支较为简洁,commit 记录也简洁一点。因为可以把多个 commit 合并成一个,有时候忘了一些小的更改,会做很多个 commit,但是只改了几行,用 rebase 就可以合成一个了。
在开发时想把最新的 master/dev 分支往自己的开发分支上合并时,如果用 merge 的话会有一条 commit 记录是 merge xxx into xxx,而 rebase 就没有。

但是 merge 会使整个记录更“全”一点

具体看团队规范,一般用git rebase的比较多。
我认为优点有如下几点:
1 rebase后最终的log历史看上去去更好看一些,方便合并前代码cr,你的提交都会是最新的几个commit 。如果你的开发分支是很早切出的,主分支上后续有很多提交,使用merge后你的记录在log里面跨度会很大。 前面同学的截图里面已经比较明显了。
2 commit log看上去记录会比较美观,例如在sourcetree中看使用rebase的情况下,左边始终是一条直线,每个feature的提交都是一个出去再回来的折线,且多个feature折线不会包含和相交。相比下merge的展示就比较糟糕了。
软件开发中,有的时候,简洁美观也是一种好的实践。

你知道吗?

宣传栏