Git 工作流程和变基与合并问题

TL;博士

git rebase 工作流不会保护您免受不擅长解决冲突的人或习惯于 SVN 工作流的人的伤害，如 Avoiding Git Disasters: A Gory Story 中所建议的那样。它只会让冲突解决对他们来说更加乏味，并且更难从糟糕的冲突解决中恢复过来。相反，请使用 diff3，这样一开始就不会那么困难。

Rebase 工作流程并不适合解决冲突！

我非常支持清理历史记录。但是，如果我遇到冲突，我会立即中止变基并进行合并！人们推荐使用 rebase 工作流程作为解决冲突的合并工作流程的更好替代方案，这真的让我很生气（这正是这个问题的意义所在）。

如果它在合并期间“全部下地狱”，它会在 rebase 期间“下地狱”，并且可能还有更多的地狱！原因如下：

原因 #1：解决一次冲突，而不是每次提交一次

当您变基而不是合并时，您将不得不执行冲突解决，次数与您提交变基的次数一样多，对于相同的冲突！

真实场景

我从 master 分支出来重构一个分支中的复杂方法。我的重构工作总共包含 15 次提交，因为我正在努力重构它并获得代码审查。我重构的一部分涉及修复以前存在于 master 中的混合制表符和空格。这是必要的，但不幸的是它会与之后在 master 中对此方法所做的任何更改相冲突。果然，当我正在研究这个方法时，有人对 master 分支中的相同方法进行了简单、合法的更改，该更改应该与我的更改合并。

当需要将我的分支与 master 合并时，我有两个选择：

git merge：我遇到了冲突。我看到他们对 master 所做的更改并将其与我的分支（的最终产品）合并。完毕。

git rebase：我的第一次提交发生了冲突。我解决了冲突并继续变基。我与第二次提交发生冲突。我解决了冲突并继续变基。我与第三次提交发生冲突。我解决了冲突并继续变基。我与第四次提交发生冲突。我解决了冲突并继续变基。我与第五次提交发生冲突。我解决了冲突并继续变基。我与第六次提交发生冲突。我解决了冲突并继续变基。我与我的第七次提交发生冲突。我解决了冲突并继续变基。我与我的第八次提交发生冲突。我解决了冲突并继续变基。我与第九次提交发生冲突。我解决了冲突并继续变基。我与第十次提交发生冲突。我解决了冲突并继续变基。我与第十一次提交发生冲突。我解决了冲突并继续变基。我与第十二次提交发生冲突。我解决了冲突并继续变基。我与我的第十三次提交发生冲突。我解决了冲突并继续变基。我与我的第十四次提交发生冲突。我解决了冲突并继续变基。我与我的第十五次提交发生冲突。我解决了冲突并继续变基。

如果这是您首选的工作流程，那您一定是在开玩笑。所需要的只是一个空白修复，它与对 master 所做的更改发生冲突，并且每次提交都会发生冲突并且必须解决。这是一个只有空格冲突的简单场景。天堂禁止您发生真正的冲突，涉及跨文件的主要代码更改，并且必须多次解决。

有了你需要做的所有额外的冲突解决，它只会增加你犯错的可能性。但是 git 中的错误很好，因为您可以撤消，对吗？当然除了...

原因 #2：使用 rebase，没有撤消！

我想我们都同意解决冲突可能很困难，而且有些人很不擅长。它很容易出错，这就是为什么 git 可以很容易地撤消它的原因！

当你合并一个分支时，git 会创建一个合并提交，如果冲突解决不顺利，它可以被丢弃或修改。即使您已经将错误的合并提交推送到公共/权威存储库，您也可以使用 git revert 撤消合并引入的更改，并在新的合并提交中正确地重做合并。

当您重新设置分支时，如果冲突解决可能出错，您就完蛋了。现在每个提交都包含错误的合并，您不能只重做 rebase*。充其量，您必须返回并修改每个受影响的提交。不好玩。

在 rebase 之后，无法确定提交的最初部分是什么，以及由于冲突解决不当而引入的内容。

*如果您可以从 git 的内部日志中挖掘旧的 refs，或者如果您创建第三个分支指向变基之前的最后一次提交，则可以撤消变基。

摆脱冲突解决：使用 diff3

以这个冲突为例：

<<<<<<< HEAD
TextMessage.send(:include_timestamp => true)
=======
EmailMessage.send(:include_timestamp => false)
>>>>>>> feature-branch

从冲突来看，不可能说出每个分支发生了什么变化或它的意图是什么。在我看来，这是解决冲突令人困惑和困难的最大原因。

diff3来救援！

git config --global merge.conflictstyle diff3

当您使用 diff3 时，每个新的冲突都会有一个第 3 部分，即合并的共同祖先。

<<<<<<< HEAD
TextMessage.send(:include_timestamp => true)
||||||| merged common ancestor
EmailMessage.send(:include_timestamp => true)
=======
EmailMessage.send(:include_timestamp => false)
>>>>>>> feature-branch

首先检查合并的共同祖先。然后比较每一方以确定每个分支的意图。您可以看到 HEAD 将 EmailMessage 更改为 TextMessage。它的意图是改变用于TextMessage的类，传递相同的参数。您还可以看到 feature-branch 的意图是为 :include_timestamp 选项传递 false 而不是 true。要合并这些更改，请结合两者的意图：

TextMessage.send(:include_timestamp => false)

一般来说：

比较每个分支的共同祖先，并确定哪个分支具有最简单的更改 将该简单更改应用到另一个分支的代码版本，使其包含更简单和更复杂的更改您刚刚将更改合并到的那个

替代：通过手动应用分支的更改来解决

最后，即使使用 diff3，有些冲突也很难理解。尤其是当 diff 发现在语义上不常见的共同行时（例如，两个分支碰巧在同一位置有一个空行！），就会发生这种情况。例如，一个分支更改类主体的缩进或重新排序类似的方法。在这些情况下，更好的解决策略可以是检查合并任一侧的更改并手动将差异应用到另一个文件。

让我们看看在合并 origin/feature1 where lib/message.rb 冲突的场景中如何解决冲突。

确定我们当前签出的分支（HEAD 或 --ours）或我们正在合并的分支（origin/feature1 或 --theirs）是否更易于应用。将 diff 与三点 (git diff a...b) 一起使用可以显示自上次与 a 分歧以来 b 发生的变化，或者换句话说，将 a 和 b 的共同祖先与 b 进行比较。 git diff HEAD...origin/feature1 -- lib/message.rb # 显示 feature1 的变化 git diff origin/feature1...HEAD -- lib/message.rb # 显示我们分支的变化 查看更复杂的文件的版本。这将删除所有冲突标记并使用您选择的一侧。 git checkout --ours -- lib/message.rb # 如果我们分支的更改更复杂 git checkout --theirs -- lib/message.rb # 如果 origin/feature1 的更改更复杂 复杂的更改签出后，向上拉较简单更改的差异（参见步骤 1）。将此差异中的每个更改应用于冲突文件。

---

“冲突”是指“同一内容的平行演化”。因此，如果它在合并期间“全部下地狱”，则意味着您在同一组文件上进行了大规模的演变。

变基比合并更好的原因是：

你用主人之一重写你的本地提交历史（然后重新应用你的工作，然后解决任何冲突）

最终的合并肯定是一个“快进”的合并，因为它将拥有 master 的所有提交历史，加上只有你的更改才能重新应用。

我确认在这种情况下正确的工作流程（公共文件集的演变）首先是变基，然后是合并。

但是，这意味着，如果您推送本地分支（出于备份原因），则不应被其他任何人拉取（或至少使用）该分支（因为提交历史记录将被连续的 rebase 重写）。

关于该主题（变基然后合并工作流程），barraponto 在评论中提到了两个有趣的帖子，均来自 randyfay.com：

Git 的 Rebase 工作流：提醒我们先获取，rebase：

使用这种技术，您的工作总是在公共分支之上进行，就像一个与当前 HEAD 保持同步的补丁一样。

（类似的技术 exists for bazaar）

避免 Git 灾难：一个血腥故事：关于 git push --force 的危险（例如，而不是 git pull --rebase）

---

在我的工作流程中，我尽可能地变基（并且我尝试经常这样做。不让差异累积会大大减少分支之间冲突的数量和严重性）。

然而，即使在大部分基于 rebase 的工作流程中，也有合并的地方。

回想一下，合并实际上创建了一个具有两个父节点的节点。现在考虑以下情况：我有两个独立的功能分支 A 和 B，现在想在依赖 A 和 B 的功能分支 C 上开发东西，而 A 和 B 正在接受审查。

然后我要做的是：

在 A 之上创建（和结帐）分支 C。将其与 B 合并

现在分支 C 包含来自 A 和 B 的更改，我可以继续开发它。如果我对 A 进行任何更改，那么我会通过以下方式重建分支图：

在 A 的新顶部创建分支 T 与 B 合并 T 将 C 重新设置到 T 上删除分支 T

这样我实际上可以维护任意的分支图，但是做一些比上述情况更复杂的事情已经太复杂了，因为没有自动工具在父项更改时进行变基。

---

几乎在任何情况下都不要使用 git push origin --mirror。

它不会询问您是否确定要这样做，而且您最好确定，因为它会清除所有不在本地机器上的远程分支。

http://twitter.com/dysinger/status/1273652486

---

在你的情况下，我认为你的伴侣是正确的。变基的好处在于，对于局外人来说，您的更改看起来就像它们都是以干净的顺序发生的一样。这表示

您的更改很容易查看

您可以继续进行良好的小型提交，但您可以一次将这些提交的集合公开（通过合并到 master 中）

当您查看公共主分支时，您会看到不同开发人员针对不同功能的不同系列提交，但它们不会全部混合

您仍然可以继续将您的私有开发分支推送到远程存储库以进行备份，但其他人不应将其视为“公共”分支，因为您将进行变基。顺便说一句，执行此操作的简单命令是 git push --mirror origin 。

文章 Packaging software using Git 很好地解释了合并与变基之间的权衡。这是一个有点不同的上下文，但原则是相同的——它基本上归结为你的分支是公共的还是私有的，以及你计划如何将它们集成到主线中。

---

看了你的解释后，我有一个问题：难道你从来没有做过

git checkout master
git pull origin
git checkout my_new_feature

在您的功能分支中执行“git rebase/merge master”之前？

因为您的 master 分支不会自动从您朋友的存储库中更新。您必须使用 git pull origin 执行此操作。即，也许你总是从一个永不改变的本地主分支变基？然后到了推送时间，您正在推送一个存储库，其中包含您从未见过的（本地）提交，因此推送失败。

---

无论如何，我在最近的一个分支上遵循我的工作流程，当我试图将它合并回 master 时，一切都变得糟糕透顶。与本应无关紧要的事情发生了很多冲突。这些冲突对我来说毫无意义。我花了一天的时间整理一切，最终以强制推送到远程 master 达到高潮，因为我的本地 master 已经解决了所有冲突，但远程 master 仍然不高兴。

在您的合作伙伴和您建议的工作流程中，您都不应该遇到没有意义的冲突。即使您有，如果您遵循建议的工作流程，那么在解决后不应要求“强制”推送。这表明您实际上并没有合并您要推送的分支，而是必须推送一个不是远程提示的后代的分支。

我认为你需要仔细看看发生了什么。其他人是否可以（有意或无意地）在您创建本地分支和您尝试将其合并回本地分支之间重绕远程主分支？

与许多其他版本控制系统相比，我发现使用 Git 涉及的工具更少，并且允许您着手解决对源流至关重要的问题。 Git 不执行魔法，因此冲突的更改会导致冲突，但它应该通过跟踪提交父级来轻松完成写入操作。

---

“即使你是一个只有几个分支的开发人员，养成使用 rebase 和正确合并的习惯也是值得的。基本的工作模式如下所示：

从现有分支 A 创建新分支 B

在分支 B 上添加/提交更改

来自分支 A 的变基更新

将分支 B 的更改合并到分支 A"

https://www.atlassian.com/git/tutorials/merging-vs-rebasing/

---

根据我的观察，即使在合并之后，git merge 也倾向于保持分支分离，而 rebase 然后合并将其合并为一个分支。后者更清晰，而在前者中，即使在合并之后也更容易找出哪些提交属于哪个分支。

---

使用 Git 没有“正确”的工作流程。使用任何漂浮你的船。但是，如果您在合并分支时经常遇到冲突，也许您应该与其他开发人员更好地协调您的工作？听起来你们两个一直在编辑相同的文件。此外，请注意空格和颠覆性关键字（即“$Id$”等）。

---

我只使用 rebase 工作流，因为它在视觉上更清晰（不仅在 GitKraken 中，而且在 Intellij 和 gitk 中，但我最推荐第一个）：你有一个分支，它起源于 master，它去回到主人。当图表干净漂亮时，您会知道没有什么会下地狱的，永远。

https://i.stack.imgur.com/B85dm.png

我的工作流程与您的工作流程几乎相同，但只有一点不同：我在 rebase 我的分支到 master 上的最新更改之前 squash 提交到本地分支中的一个，因为：

rebase 根据每个提交工作

这意味着，如果您有 15 次提交更改了与 master 相同的行，则如果您不压缩，则必须检查 15 次，但重要的是最终结果，对吧？

所以，整个工作流程是：

签出到master并拉取以确保您拥有最新版本从那里，创建一个新分支在那里做您的工作，您可以自由提交多次，并推送到远程，不用担心，因为它是您的分支。如果有人告诉你，“嘿，我的 PR/MR 被批准了，现在它被合并到 master”，你可以获取它们/拉取它们。你可以在任何时候做，也可以在第 6 步做。在做完所有工作后，提交它们，如果你有几个提交，则压缩它们（它们都是你的工作，你改变多少次代码行无关紧要；唯一重要的是最终版本）。推不推，无所谓。结帐到 master，再次拉取以确保您在本地拥有最新的 master。您的图表应与此类似：

https://i.stack.imgur.com/GntcK.png

如您所见，您位于本地分支上，该分支源于 master 上的过时状态，而 master（本地和远程）随着您同事的变化而向前发展。

结帐回您的分支，然后变基为 master。您现在将只有一次提交，因此您只需解决一次冲突。（在 GitKraken 中，您只需将您的分支拖到 master 并选择“Rebase”；我喜欢它的另一个原因。）之后，您将像：

https://i.stack.imgur.com/tCSGE.png

所以现在，您拥有最新 master 上的所有更改，以及您的分支上的更改。您现在可以推送到您的遥控器，如果您之前推送过，您将不得不强制推送； Git 会告诉你不能简单地快进。这很正常，因为 rebase，你已经改变了你的分支的起点。但你不应该害怕：明智地使用武力，但不要害怕。最后，远程也是你的分支，所以即使你做错了也不会影响 master。创建 PR/MR 等到审核通过，master 会有你的贡献。恭喜！因此，您现在可以结帐以掌握、提取更改并删除本地分支以清理图表。如果在将远程分支合并到 master 时没有这样做，远程分支也应该被删除。

最终的图表再次清晰明了：

https://i.stack.imgur.com/CljEO.png

---