时间戳

首页 > 解决方案 > git pull 与 git pull --rebase

git - git pull 与 git pull --rebase

问题描述

参考这个写得很好的答案：https ://stackoverflow.com/a/4675513/1139436

如果你真的觉得出于某种原因需要某个东西成为一个分支......

“分支”在这里指的是什么？在我们的工作流程中，我们将 master 分支出来进行错误修复、新功能等，然后将这些更改推送到 gerrit 进行审查，一旦获得批准，（我假设我没有设置它）将它们合并到 master 中。这些是被引用的分支，还是评论指的是更大的东西（项目分歧等）？

回到我们的工作流程......提交更改后，我们git checkout master、git pull* 和git branch -D bugfix_branch. 我用 * 标记了 pull，因为这经常导致我本地 master 中的合并提交。我开始使用git pull --rebase并且不再看到那些合并提交，但我承认，我根本不明白引擎盖下发生了什么。

为什么我看到合并提交，我想要它们吗？我能更好地--rebase避开它们吗？无论哪种方式，似乎都没有人有答案，只要它“正常工作”。

标签： gitbranch

解决方案

最终，关于是否使用面向合并的工作流程、面向变基的工作流程或某种混合的决定——即两者都使用，根据判断选择哪一个——是一个见仁见智的问题，好吧，判断。1 双方都有很好的论据。这里有两个外部意见页面，一个是 Ken Sheedlo 支持 rebase 的页面，另一个是列出双方的论点的页面，以及关于合并与rebase 的Atlassian 教程页面。

关于 rebase 要实现的事情是它复制（一些）提交。如果您了解将提交表示为图形的Git 模型2，Ken Sheedlo 的 pro-rebase 参数中的示例将向您确切说明这意味着什么：原始提交B和C：

  B--C   <-- feat
 /
A--D--E   <-- master

象征性地被狼群抛弃，有利于闪亮的新替代品B'，并且C'：

  B--C   [abandoned]
 /
A--D--E   <-- master
       \
        B'-C'  <-- feat

B-C用闪亮的新提交链替换了枯燥的 icky 旧链B'-C'，新功能分支现在可以无缝地合并到master，无论是否合并提交。使用合并提交（git merge --no-ff feat在打开时运行）master为您提供此图：

A--D--E------F   <-- master
       \    /
        B'-C'  <-- feat

这有助于历史学家在未来出现（一旦名称feat被删除，这是安全的，因为F记住C'以及E）并看到提交对,B'-C'是实现该功能的原因。这是否有价值，而不是看起来更简单：

A--D--E--B'-C'  <-- master

是一个单独的问题。但是，由于变基，真正的原始提交已经丢失了。B--C如果这个事实由于某种原因很重要，那么你确实因为变基而失去了一些东西。

简而言之，这就是反对变基的论点：你可能会失去一些重要的历史。 支持 rebase 的论点是，这些历史片段不仅不重要，而且会积极干扰理解。许多计算机编程都是关于抽象的，而抽象是去除不必要细节的艺术。3 这为您提供了一个很好的“大局”视图。一旦你了解了你现在在哪里以及你想去哪里，那么你就可以绘制出你如何到达这里以及如何到达那里的细节。如果您迷失在细节的杂草中并且不知道自己在哪里以及要去哪里，那么您最多会幸运地进行某种布朗运动。

1关于是否用额外的“e”拼写判断也是如此：http : //grammarist.com/spelling/judgment-judgement/，https ://www.dictionary.com/e/judgement-vs-judgment/

2如果您不这样做，请浏览Think Like (a) Git中的页面。

3数学也是如此。图论本身源于去除不必要的细节：欧拉意识到所有重要的是桥梁和陆地。（见脚注 2 中的链接。）

推荐阅读