因此，如果我使用的是远程（跟踪）分支的分支，并且我想得到最新的分支，我仍然不清楚我应该做git pull还是git rebase。我以为我已经读过在与其他用户一起工作时正在做git rebase，当他们拉动或重新绑定时，它可以搞砸了。真的吗？我们都应该使用git pull吗？
答案 0 :(得分：51)
Git pull是2个命令的组合
git rebase只是git merge的粗略等价物。它无法远程获取任何内容。事实上，它也没有进行适当的合并，它重放了你在第二个分支的新提交后所站立的分支的提交。
其目的主要是让您拥有更清晰的历史。在gitk过去的历史中，很多人并没有需要很多合并才能获得意大利面条。
最好的图形说明可以在前2个图形here中看到。但是，让我在这里用一个例子来解释。
我有2个分支：master和mybranch。站在mybranch上我可以跑
git rebase master
我将在mybranch中最近的提交之前插入master中的任何新内容。这是完美的，因为如果我现在在master中合并或重新绑定mybranch中的东西，我的新提交会在最近的提交后线性添加。
如果我向“错误”的方向转折，你提到的问题就会发生。如果我刚刚获得了最新的主人（有了新的更改），并且从主人那里我就像这样（在同步我的分支之前）改变了：
git rebase mybranch
现在我刚刚做的是我在master过去的某个地方插入了我的新变化。提交的主线已经改变。由于git与commit id一起工作的方式，所有刚刚在我的新更改中重放的提交都有新的ID。
嗯，用语言解释有点难...希望这有点道理： - ）
无论如何，我自己的工作流程是这样的：
最后一句话。我强烈建议在差异微不足道时使用rebase（例如，处理不同文件或至少不同行的人）。它有我试图在那里解释的问题，但它使历史更加清晰。
一旦出现重大冲突（例如同事已在一堆文件中重命名），我强烈建议合并。在这种情况下，系统会要求您解决冲突，然后提交解决方案。从好的方面来说，当存在冲突时，合并更容易解决。不好的一面是，如果很多人确实合并，你的历史可能会变得难以理解： - ）
祝你好运！答案 1 :(得分：10)
Git rebase是对历史的重写。你永远不应该在“公共”的分支机构（即你与他人共享的分支机构）上这样做。如果有人克隆你的分支，然后你重新分支那个分支 - 那么他们就不能再从你的分支中提取/合并更改 - 他们将不得不扔掉他们的旧分支并重新拉动。
关于packaging software with git的这篇文章非常值得一读。它更多的是关于管理软件分发，但它非常技术性，并讨论如何使用/管理/共享分支。他们谈论什么时候改变什么时候以及什么时候拉动以及各自的后果是什么。
简而言之，他们都有自己的位置，但你需要真正理解差异。
答案 2 :(得分：6)
git pull会进行合并。 git rebase重写您必须相对于远程分支的提示的任何现有提交。它们之间的相似之处在于它们都可能导致冲突，但我认为如果能够实现更顺畅的协作，则使用git rebase。在rebase操作期间，您可以优化提交，使它们看起来像是新应用于远程分支的最新版本。合并可能更适合具有更多历史记录的分支上的更长的开发周期。
与git中的大多数其他内容一样，有许多重叠功能可以适应不同的工作方式。
答案 3 :(得分：2)
查看Branching and merging上的优秀Gitcasts以及rebasing。
答案 4 :(得分：0)
如果你想在不影响远程分支的情况下提取源代码而本地副本没有任何变化，最好使用git pull。
我相信如果您有一个已经进行了更改的工作分支，使用git rebase将该分支的基础更改为最新的远程主服务器，您将保留所有分支更改，但是分支现在将分支从主要位置，而不是以前从哪里分支。