什么时候应该使用git pull
我知道有些人默认使用git pull --rebase ，还有一些人坚持不使用它。 我相信我理解合并和重新绑定之间的区别，但我试图将其放在git pull的上下文中。 难道只是不想看到很多合并提交消息，还是有其他问题？
你应该使用git pull --rebase
确实 - 为什么不呢？ 这更清晰，并且不会对您的提交强加逻辑分组。
好吧，我想这需要一些澄清。 在Git中，你可能知道，你被鼓励分支和合并。 您的本地分支，您将更改拖入其中，远程分支实际上是不同的分支，而git pull则是关于合并它们。 这是合理的，因为你不常推动，通常在构成完整功能之前积累许多变化。
然而，有时 - 无论出于何种原因 - 你认为如果这两个地方 - 偏远地区 - 只是一个分支，情况会更好。 就像在SVN中一样。 在这里， git pull --rebase发挥作用。 你不再合并 - 你实际上在远程分支之上提交。 这就是它的实际情况。
无论危险与否，您是否将本地和远程分支视为一个不可分割的事物。 有时候这是合理的（当你的变化很小，或者如果你在一个强大的开发的开始，当小的提交引入重要的变化时）。 有时候不是（当你通常创建另一个分支，但你却懒得这么做）。 但这是一个不同的问题。
我想对“git pull --rebase”实际上意味着什么提供不同的观点，因为它似乎有时会丢失。
如果你曾经使用过Subversion（或CVS），你可能习惯了“svn update”的行为。 如果您有更改提交，并且提交失败，因为更改已在上游进行，则您“svn update”。 Subversion通过将上游更改与您的合并进行，可能会导致冲突。
Subversion刚刚做了什么，实质上是“拉回 - 基础”。 重新制定本地变更与新版本相关的行为是其“重新分配”部分。 如果在失败的提交尝试之前完成了“svn diff”，然后比较产生的差异和“svn diff”的输出，则两个差异之间的差异就是重新构建操作所做的。
在这种情况下，Git和Subversion之间的主要区别在于，在Subversion中，“您的”更改只存在于您的工作副本中未提交的更改，而在Git中本地实际提交。 换句话说，在Git中，你分叉了历史; 你的历史和上游历史已经分歧，但你有一个共同的祖先。
在我看来，在你的本地分支简单地反映上游分支并对其进行持续开发的正常情况下，正确的做法总是“--rebase”，因为这就是你在语义上实际上正在做的事情。 你和其他人正在窃取分支预期的线性历史。 事实上，其他人碰巧在你尝试推动之前碰巧推迟了这一事实是无关紧要的，而且对于每一次导致历史合并的这种时间安排的事故似乎都适得其反。
如果你真的觉得无论出于什么原因都需要某个分支，那在我看来这是一个不同的问题。 但是除非你有一个特定而积极的愿望来表达你的改变，否则在我看来，默认行为应该是“git pull --rebase”。
请考虑其他需要观察和了解项目历史的人。 你是否希望历史上遍布着数以百计的合并历史，或者你是否希望只选择少数合并代表有意识的不同发展努力的合并？
我想你应该在与同一分支上的其他人合作时使用git pull --rebase 。 你正在工作→提交→工作→提交周期，当你决定推动你的工作时，你的推送被拒绝，因为同一分支上有同样的工作。 在这一点上，我总是做一个pull --rebase 。 我不使用压扁（压扁提交），但为了避免额外的合并提交，我重新设置了密码。
随着你的Git知识的增加，你会发现自己在历史上比在我用过的任何其他版本控制系统中看到的要多得多。 如果你有很多小的合并提交，很容易失去你历史上发生的更大图片的焦点。
这实际上是我重新绑定（*）的唯一时间，而我的工作流程的其余部分是基于合并的。 但只要你最频繁的提交者这样做，最后历史看起来好多了。
（*）在教授Git课程的同时，我让一名学生逮捕了我，因为在某些情况下我还主张重新设置特色分支。 他已经读过这个答案;）这种重新设定也是可能的，但它总是必须按照预先安排/同意的系统进行，因此不应该“总是”应用。 那时我通常也不会做pull --rebase ，这就是问题所在;）
上一篇: When should I use git pull
下一篇: Unable to push reverted file to repository after git reset