git pull --rebase有什么优势 ?

Question

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

Answer 1

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

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

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

Answer 2

你是要问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...

Answer 3

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

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

Answer 4

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