我知道有些人git pull --rebase默认使用，而另一些人则坚持不使用它。我相信我了解合并和重新定级之间的区别，但是我试图将其放在的背景下git pull。是否只是不想看到很多合并提交消息，还是有其他问题？
Answers:
你应该用git pull --rebase什么时候
确实-为什么不呢？更清楚一点，并且不会对提交进行逻辑分组。
好的，我想需要澄清一下。您可能知道，在Git中，建议您进行分支和合并。实际上，您将更改引入到的本地分支和远程分支是不同的分支，并且git pull它们是关于合并它们的。这是合理的，因为您不经常推送，并且通常会在构成完整功能之前积累许多更改。
但是，有时，无论出于何种原因，您都认为如果将远程和本地这两个作为一个分支实际上会更好。就像在SVN中一样。在这里git pull --rebase发挥作用。您不再合并-您实际上是在远程分支之上提交。这就是实际上的意思。
危险与否是您是否将本地和远程分支视为不可分割的问题。有时这是合理的（当您的更改很小时，或者如果您处于健壮的开发的开始，而小的更改带来了重要的更改）。有时不是（通常创建另一个分支，但是您懒得这么做）。但这是一个不同的问题。
git config --global pull.rebase preserve （保留表示除了启用变基外，如果您在本地进行合并，则尝试保留合并）。
我想对“ git pull --rebase”的实际含义提供不同的看法，因为它有时会迷路。
如果您曾经使用过Subversion（或CVS），则可能会习惯于“ svn更新”的行为。如果您有要提交的更改，并且由于在上游进行了更改而导致提交失败，请“ svn更新”。颠覆是通过将上游变更与您的变更合并而进行的，有可能导致冲突。
Subversion所做的基本上是“拉--rebase”。重新构造本地更改以使其相对于较新版本的行为是该过程的“基础”部分。如果您在失败的提交尝试之前完成了“ svn diff”，然后将生成的diff与之后的“ svn diff”的输出进行比较，则这两个diff之间的差异就是重新设置基准的操作。
在这种情况下，Git和Subversion之间的主要区别在于，在Subversion中，“您的”更改仅作为未提交的更改存在于您的工作副本中，而在Git中，您具有本地的实际提交。换句话说，您在Git中创造了历史。您的历史和上游历史有所不同，但是您有共同的祖先。
在我看来，在具有当地分行只是反映了上游分支并在其上做持续发展的正常情况下，做正确的事永远是“--rebase”，因为那是你在语义上真正是什么做的。您和其他人正在破坏分支的预期线性历史记录。有人在您尝试进行推送之前碰巧稍稍推动了这一事实是无关紧要的，并且对于每次这样的时间错误事件（导致历史合并）似乎都适得其反。
如果您实际上出于某种原因感到需要某种东西成为分支机构，那么我认为这是另一个问题。但是，除非您有明确而积极的愿望以合并的形式表示您的更改，否则我认为默认行为应为“ git pull --rebase”。
请考虑需要观察和了解您的项目历史的其他人。您是否要在整个地方散布着数百个合并的历史记录，还是只希望选择少数几个表示有意进行不同开发工作的真正合并的合并？
git config --global branch.autosetupmerge always吗？
也许最好的解释方法是举一个例子：
git checkout master && git pull。主人已经是最新的。git checkout master && git pull。主人已经是最新的。git merge topic-branch-Agit merge topic-branch-Bgit push origin master在爱丽丝面前做git push origin master，因为它不是快速合并，所以被拒绝。git pull --rebase origin mastergit push origin master，每个人都很高兴他们将来在查看日志时不必读取无用的合并提交。注意，合并到的特定分支与该示例无关。在此示例中，Master可以很容易地成为release分支或dev分支。关键是Alice和Bob正在同时将其本地分支合并到共享的远程分支。
git co master && git pull; git checkout topic-branch-A; git rebase master; git checkout master; git merge topic-branch-A; git push origin master如果别人的推动力发生在我的面前，我会重复一遍。虽然我可以在您的食谱中看到简洁的优势。
我认为git pull --rebase与同一个分支上的其他人协作时应该使用。您处于工作→提交→工作→提交周期，并且当您决定推送您的工作时，您的推送被拒绝，因为在同一分支上存在并行工作。在这一点上我总是做一个pull --rebase。我不使用squash（展平提交），但我重新设置基准以避免额外的合并提交。
随着Git知识的增加，您发现自己对历史的了解要比我使用过的任何其他版本控制系统都要多。如果您有大量的小型合并提交，则很容易失去对历史上正在发生的大局面的关注。
实际上，这是我唯一一次进行rebasing（*）的时间，其余的工作流基于合并。但是，只要您最频繁的提交者这样做，历史最终就会好得多。
（*）在教授Git课程时，有一位学生因此而被捕，因为在某些情况下我还主张重新设置要素分支。他已经读过这个答案了；）这样的重新定基也是可能的，但是它总是必须根据预先安排的/商定的系统进行，因此不应“始终”应用。那时我通常都不做pull --rebase，这就是问题所在；）
我认为没有理由不使用它pull --rebase-我在Git中添加了代码，专门用于使我的git pull命令始终根据上游提交进行基准调整。
查看历史记录时，知道从事该功能的人/男何时停止同步就变得很有趣。这对男/女在他/她这样做时可能很有用，但这就是reflog目的。这只是给其他所有人增加了噪音。
pull --rebase应该始终使用，pull默认情况下为什么不这样做？
.gitconfig要使某些选项做正确的事情。我认为git rebase在默认情况下会做错事，git tag等也是如此。如果您不同意，则无需证明自己的观点。
master，这似乎是个好建议，并且如果您进入的分支尚未公开（还）。另一方面，如果您从功能分支中拉入master，则更像是相反：永远没有理由使用--rebase，对吧？这可能就是为什么它不是默认值的原因。我发现Rebases是更改应如何从层次结构的顶部向下传递，而合并是它们如何向上流动。 derekgourlay.com/blog/git-when-to-merge-vs-when-to-rebase
我认为这归结为个人喜好。
您要隐藏您的愚蠢错误，然后再进行更改吗？如果是这样，那git pull --rebase是完美的。它允许您稍后将提交压缩为几个（或一个）提交。如果您在（未推送的）历史记录中进行了合并，那么进行下一个合并并非易事git rebase。
我个人不介意发布所有愚蠢的错误，因此我倾向于合并而不是重新设置基础。