因此，如果我使用的是远程（跟踪）分支的分支，并且我想获得最新的，我仍然不清楚我是否应该做git pull或git rebase. 我以为我在与其他用户一起在分支上工作时读过这git rebase句话，当他们拉动或变基时，它可能会把他们搞砸。真的吗？我们都应该使用git pull吗？
cdb
问问题
14850 次
5 回答
52
git pull 是 2 个命令的组合
- git fetch (同步你的本地仓库和远程最新的东西)
- git merge（将远程分支的更改（如果有）合并到您的本地跟踪分支中）
git rebase 只是粗略地等同于 git merge。它不会远程获取任何东西。事实上，它也没有进行适当的合并，它会在第二个分支的新提交之后重播您所在分支的提交。
它的目的主要是让你有一个更干净的历史。在 gitk 的过去历史变得非常像意大利面条之前，不需要很多人进行多次合并。
最好的图形解释可以在这里的前 2 个图形中看到。但是让我在这里用一个例子来解释一下。
我有 2 个分支：master 和 mybranch。当站在 mybranch 上时，我可以跑
git rebase master
在我最近提交到 mybranch 之前，我会在 master 中插入任何新内容。这是完美的，因为如果我现在在 master 中合并或 rebase mybranch 中的内容，我的新提交将在最近的提交之后线性添加。
如果我在“错误”的方向上变基，你提到的问题就会发生。如果我刚刚获得了最新的 master（有新的更改）并且从 master 我像这样重新设置基准（在同步我的分支之前）：
git rebase mybranch
现在我所做的是我在主人过去的某个地方插入了我的新更改。提交的主线已更改。由于 git 使用提交 id 的方式，所有刚刚通过我的新更改重放的提交（来自 master）都有新的 id。
好吧，用语言来解释有点困难......希望这有点道理:-)
无论如何，我自己的工作流程是这样的：
- 'git pull' 来自远程的新更改
- 切换到我的分支
- 'git rebase master' 在我的提交历史中带来 master 的新变化
- 切换回主人
- 'git merge mybranch'，仅当 master 中的所有内容也在 mybranch 中时才会快进（从而避免公共分支上的提交重新排序问题）
- '混帐推'
最后一句话。我强烈建议在差异很小的情况下使用 rebase（例如，人们处理不同的文件或至少在不同的行上工作）。它有我试图在上面解释的问题，但它使历史更加清晰。
一旦可能存在重大冲突（例如，同事重命名了一堆文件中的某些内容），我强烈建议合并。在这种情况下，系统会要求您解决冲突，然后提交解决方案。从好的方面来说，当存在冲突时，合并更容易解决。不利的一面是，如果很多人一直在合并，您的历史可能会变得难以追随:-)
祝你好运！
于 2008-09-18T21:01:49.097 回答
10
Gitrebase是对历史的改写。您永远不应该在“公共”分支（即您与他人共享的分支）上执行此操作。如果有人克隆了你的分支，然后你重新设置了那个分支——那么他们就不能再从你的分支中拉取/合并更改——他们将不得不扔掉旧的分支并重新拉取。
这篇用 git 打包软件的文章非常值得一读。它更多的是关于管理软件发行版，但它非常技术性并且讨论了如何使用/管理/共享分支。他们谈论什么时候变基，什么时候拉动，以及每种方法的各种后果是什么。
简而言之，它们都有自己的位置，但您需要真正了解差异。
于 2008-09-18T23:43:39.833 回答
6
git pull如果您的提交不在远程分支中，则进行合并。git rebase重写您必须与远程分支的尖端相关的任何现有提交。它们的相似之处在于它们都可能导致冲突，但我认为git rebase如果可以的话，使用可以让协作更顺畅。在 rebase 操作期间，您可以优化您的提交，使它们看起来像是新应用到远程分支的最新版本。合并可能更适合具有更多历史的分支上更长的开发周期。
像 git 中的大多数其他东西一样，有很多重叠的功能来适应不同的工作风格。
于 2008-09-18T20:38:08.110 回答
0
如果您想在不影响远程分支且不更改本地副本的情况下拉取源代码，最好使用 git pull。
我相信如果您有一个工作分支并进行了更改，请使用 git rebase 将该分支的基础更改为最新的远程 master，您将保留所有分支更改，但是该分支现在将从 master 分支位置，而不是之前分支的位置。
于 2008-09-18T20:38:55.580 回答