在什么情况下`git pull`是有害的？

Question

我有一位同事声称git pull有害，并且每当有人使用它时都会感到不安。

git pull命令似乎是更新本地存储库的规范方法。使用git pull会产生问题吗？它创造了什么问题？有没有更好的方法来更新git存储库？

Answer 1

我的回答，摘自arose关于HackerNews的讨论：

我很想用热门新闻头条新闻回答这个问题：为什么git pull被视为有害？事实并非如此。

• 非线性不是本质上不好的。如果它们代表了实际的历史，那么它们就可以了。
• 意外重新引入提交重新上游是上游错误重写历史的结果。当历史沿着几个回购复制时，您无法重写历史记录。
• 修改工作目录是预期的结果;有争议的有用性，即面对hg / monotone / darcs / other_dvcs_predating_git的行为，但又不是本质上不好。
• 合并需要暂停审查其他人的工作，并且再次成为git pull的预期行为。如果您不想合并，则应使用git fetch。同样，与以前流行的dvcs相比，这是git的特质，但它是预期的行为而不是本质上不好的。
• 很难对远程分支进行反驳是很好的。除非你绝对需要，否则不要重写历史。我不能为我的生活理解这种（假的）线性历史的追求
• 不清理树枝是好的。每个回购都知道它想要持有什么。 Git没有主从关系的概念。

Answer 2

如果您正确使用Git，则认为不会有害。鉴于您的用例，我看到它对您产生的负面影响，但您可以通过不修改共享历史记录来避免问题。

Answer 3

接受的答案声称

  

无法将rebase-pull操作配置为保留合并

但是从Git 1.8.5开始，这个帖子就是答案，你可以

git pull --rebase=preserve

或

git config --global pull.rebase preserve

或

git config branch.<name>.rebase preserve

docs说

  

当preserve,也将--preserve-merges传递给'git rebase'时，运行'git pull'不会使本地提交的合并提交变平。

前面的讨论有更详细的信息和图表：git pull --rebase --preserve-merges。它还解释了为什么git pull --rebase=preserve与git pull --rebase --preserve-merges不同，后者没有做正确的事。

此前的其他讨论解释了rebase的保留合并变体实际上做了什么，以及它如何比常规rebase复杂得多：What exactly does git's "rebase --preserve-merges" do (and why?)

Answer 4

如果您转到旧的git存储库 git up ，则它们建议的别名是不同的。 https://github.com/aanand/git-up

git config --global alias.up 'pull --rebase --autostash'

这对我来说很完美。