Git - 与其他人一起处理分支时是拉取还是变基

Question

因此，如果我使用的是远程（跟踪）分支的分支，并且我想获取最新的分支，我仍然不清楚我是否应该这样做 git pull 或者 git rebase. 。我以为我读过那件事 git rebase 当与其他用户一起在一个分支上工作时，当他们拉取或重新建立基础时，它可能会把他们搞砸。真的吗？我们都应该使用 git pull?

Answer 1

Git pull 是 2 个命令的组合

• git fetch （将本地存储库与远程上的最新内容同步）
• git merge（将远程分支的更改（如果有）合并到本地跟踪分支中）

git rebase 只是大致相当于 git merge。它不会远程获取任何内容。事实上，它也没有进行正确的合并，它会在第二个分支的新提交之后重放您所在分支的提交。

它的目的主要是让你有一个更干净的历史记录。在 gitk 的过去历史变得非常像意大利面条之前，不需要很多人进行多次合并。

最好的图形解释可以在前两张图中看到 这里. 。但让我在这里用一个例子来解释一下。

我有2个分支机构：master 和 mybranch。当站在我的树枝上我可以奔跑

git rebase master

我会在 mybranch 中最近提交之前插入 master 中的任何新内容。这是完美的，因为如果我现在合并或重新调整 master 中 mybranch 的内容，我的新提交将在最近的提交之后线性添加。

如果我在“错误”的方向上变基，就会发生您提到的问题。如果我刚刚获得最新的主控（带有新的更改），并且从主控开始，我会像这样进行变基（在同步我的分支之前）：

git rebase mybranch

现在我刚刚所做的是将我的新更改插入到 master 过去的某个位置。提交的主线已更改。由于 git 使用提交 ID 的方式，刚刚在我的新更改上重播的所有提交（来自 master）都有新的 ID。

嗯，只是用语言来解释有点困难......希望这有点道理:-)

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

• 从远程“git pull”新更改
• 切换到我的分支
• “git rebase master”将 master 的新更改带入我的提交历史记录中
• 切换回主模式
• 'git merge mybranch'，仅当 master 中的所有内容也在 mybranch 中时才快进（从而避免公共分支上的提交重新排序问题）
• 'git 推'

最后一句话。我强烈建议当差异很小时使用 rebase（例如人们在不同的文件或至少不同的行上工作）。它有我试图解释的陷阱，但它使历史变得更加清晰。

一旦可能出现重大冲突（例如一位同事重命名了一堆文件中的某些内容），我强烈建议合并。在这种情况下，系统会要求您解决冲突，然后提交解决方案。从好的方面来说，当存在冲突时，合并更容易解决。不利的一面是，如果很多人一直进行合并，您的历史可能会变得难以理解:-)

祝你好运！

Answer 2

git rebase 是历史的改写。您永远不应该在“公共”分支（即您与他人共享的分支）上执行此操作。如果有人克隆了你的分支，然后你对该分支进行变基——那么他们就不能再从你的分支中拉取/合并更改——他们将不得不扔掉旧的分支并重新拉取。

这篇文章关于 用git打包软件 是一本非常值得一读的书。它更多的是关于管理软件发行版，但它非常技术性，并讨论如何使用/管理/共享分支。他们讨论何时重新设置基准、何时拉取以及每种情况的各种后果是什么。

简而言之，它们都有自己的位置，但您需要真正体会其中的差异。

Answer 3

git pull 如果您的提交不在远程分支中，则进行合并。 git rebase 重写您必须相对于远程分支的提示的任何现有提交。它们的相似之处在于它们都会引起冲突，但我认为使用 git rebase 如果可以的话，可以让协作更加顺利。在变基操作期间，您可以优化提交，使它们看起来像是新应用到远程分支的最新版本的。合并可能更适合具有更多历史记录的分支上的较长开发周期。

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

Answer 4

查看精彩的 Gitcast 分支和合并 也 重新定位.

Answer 5

如果您想拉取源代码而不影响远程分支并且不对本地副本进行任何更改，最好使用 git pull。

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