因此，如果我使用的是远程(跟踪)分支，并且希望获得最新的分支，我仍然不清楚应该执行git pull还是git rebase。我以为我读过与其他用户一起在分支上工作时执行git rebase，当他们拉动或者重新设置基准时可能会搞砸他们。真的吗？我们都应该使用git pull吗？

解决方案

如果我们有不在远程分支中的提交，git pull会进行合并。 git rebase重写所有必须相对于远程分支的尖端的现有提交。它们的相似之处在于它们都可能导致冲突，但是我认为如果可以允许更顺畅的协作，可以使用git rebase。在rebase操作期间，我们可以优化提交，使它们看起来像是新应用于远程分支的最新修订版。对于具有更多历史记录的分支上较长的开发周期，合并可能更合适。

像git中的其他大多数东西一样，有很多重叠的功能可以适应不同的工作风格。

如果我们想在不影响远程分支的情况下提取源代码，并且在本地副本中不进行任何更改，则最好使用git pull。

我相信，如果我们有一个已更改的工作分支，请使用git rebase将该分支的基础更改为最新的远程主服务器，我们将保留所有分支更改，但是该分支现在将从主服务器分支位置，而不是先前分支的位置。

Git pull是2个命令的组合

• git fetch(将本地存储库与远程服务器上的最新内容同步)
• git merge(将来自远程分支(如果有的话)的更改合并到本地跟踪分支中)

git rebase仅大致等同于git merge。它不会远程获取任何内容。实际上，它也没有进行正确的合并，它会在第二个分支中的新提交之后重播我们所在分支的提交。

其目的主要是让我们拥有更清晰的历史记录。在gitk的过去历史变得非常像意大利面条之前，不需要很多人进行很多合并。

最好的图形说明可以在此处的前2个图形中看到。但让我在这里举例说明。

我有2个分支：master和mybranch。站在mybranch时，我可以跑步

git rebase master

并且在mybranch中进行最新提交之前，我将在master中插入任何新内容。这是完美的，因为如果现在我将master内mybranch中的内容合并或者重新建立基础，则新提交将在最近的提交之后线性添加。

如果我根据"错误"的方向重新定位，则会发生我们所指的问题。如果我刚刚获得了最新的主服务器(具有新更改)，并且从主服务器我重新设置了基准(在同步分支之前)：

git rebase mybranch

现在，我所做的就是将新更改插入到master的某个位置。提交的主线已更改。由于git使用提交ID的方式，刚刚在我的新更改中重播的所有提交(来自master)都具有新的id。

好吧，用语言很难解释...希望这有点道理:-)

无论如何，我自己的工作流程是这样的：

• 'git pull'远程的新变化
• 切换到mybranch
• 'git rebase master'在我的提交历史中带来master的新变化
• 切换回主人
• 'git merge mybranch'，仅当master中的所有内容也在mybranch中时才快速前进(从而避免了公共分支上的提交重新排序问题)
• 'git push'

最后一句话。我强烈建议我们在差异不大时使用rebase(例如，使用不同文件或者至少不同行的人)。它有我试图解释的陷阱，但是它使历史更加清晰。

一旦发生重大冲突(例如，同事已将一堆文件中的某项重命名)，我强烈建议合并。在这种情况下，系统会要求我们解决冲突，然后提交解决方案。从正面来看，发生冲突时合并更容易解决。不利的一面是，如果很多人一直都在合并，历史记录可能会变得很难掌握:-)

祝你好运！

Gitrebase是对历史的重写。我们绝对不应在"公共"分支(即与他人共享的分支)上执行此操作。如果有人克隆了分支，然后我们对该分支进行了重新设置-那么他们将无法再从分支中提取/合并更改-他们将不得不丢弃旧的分支并重新拉出。

关于使用git打包软件的这篇文章非常值得一读。它更多地是关于管理软件发行版的，但是它是技术性的，并且讨论了如何使用/管理/共享分支。他们讨论何时需要重新设置基础，何时需要重新使用以及它们各自带来的各种后果。

简而言之，它们都有自己的位置，但是我们需要真正地把握住两者之间的差异。

在分支和合并以及重新定基础方面查看出色的Gitcast。