3

我在一个同时使用多个分支的项目中使用 git，即：

A ---- B ---- C
 \       \
  \       ---- D
   ---- E

根据情况使用每个命名项目（即我需要同时访问 A、B 和 D...）。当我修改代码时，我会在我能做到的更高相关分支（主要是 A）中进行修改，然后将每个分支重新定位到新的“A”以传播差异。

由于我被告知这是一个坏习惯，因为它会产生推/拉问题，现在我必须在我的项目中添加一个新的维护者，我想有另一种方式来做我想做的事。

有人建议我做条件编译，这是我早期开发的方式，但是现在我有很多分支（目前大约 10 个）并且代码变得非常难以阅读，这就是我来这个分支解决方案的原因...

Cherry-picking 看起来很棒，但是每次提交都会进行 10 次提交，并且我们失去了 B 是 A 的孩子这一事实的“视觉”表示......

任何其他想法，建议？谢谢！

4

1 回答 1

3

只需使用“git merge”而不是“git rebase”。

假设一个错误出现在图表的分支 A 中。它是显示错误的最上游分支，因此这就是您要修复的。你检查它，编写修复代码，测试修复，并确认它在 A 上有效。然后，当你想在其他任何地方传播它时，你：

  1. 结帐 B 并将 A 合并到 B 中。
  2. 检出 E 并将 A 合并到 E 中。
  3. 签出 C 并将 B 合并到 C 中。
  4. 签出 D 并将 B 合并到 D 中。

如果问题首先出现在 B 中，您将检查 B、编写修复代码、测试修复，然后只执行步骤 3 和 4。

在此页面上搜索“向上合并”以获取更多信息。

这确实会导致许多合并操作，如果您修复 A（10 个后代分支的父分支），则在您的示例中为 10 个，但这也是您可以使用的最合理的工作流程，不会 a) 使您的协作者发疯，因为重新提交的提交不断被推送到远程，并且b）不会完全破坏您将分支合并到另一个的能力。

b)顺便说一句，这就是为什么你不想要 'git cherry-pick' 的原因。当然，Cherry-pick 会将您的更改集从 A 传播到 10 个其他分支，但它会在它使用的每个不同分支中更改该提交的 SHA1 哈希。例如，如果您在以后将 B 合并到 A 中，那么您最终会得到冗余的历史记录：它们所做的更改集是相同的，但具有完全不同的 SHA1 哈希值。有时这并不是什么大不了的事，但是如果您将其编入您的工作流程中，它将以悲惨的方式使您失望。冗余的合并历史也会破坏 'git bisect' 和 'git rebase'，并且几乎无法阅读。对于这个分支模型，尽可能避免使用“git cherry-pick”。

于 2012-06-11T15:59:55.997 回答