git - 功能分支中的错误修复

Question

我们将Vincent Driessen的一个成功的 Git 分支模型用于我们的分支模型。一切都很好，但我还没有真正看到提出的特定问题。

据我了解，当需要新功能时，您将分支development并创建一个新feature分支。你会处理这个，当你完成后，你会将此分支合并到development分支中。

如果开发人员制作了一个功能，然后将该功能合并回来，却development发现功能代码中存在一些错误，该怎么办。这应该在哪里解决？是否应该从开发开始一个新的fix/分支并在那里修复代码？bugfix我看不到另一种方式。

应该怎么做呢？

谢谢

Answer 1

请记住，模型只是一个模型——它是关于给你一个让你更有效率的结构，而不是盲目地遵循一套规则。这意味着您应该随意调整事物并找出适合您的情况的方法，因为它可能并非在所有情况下都有效。

我认为您在这种情况下可以选择：

1. 回滚合并并继续在功能分支上工作，直到它准备好
2. 启动一个新分支来修复这个错误。

您选择哪一个取决于以下因素：

• 您的客户能看到错误吗？制作错误修复或修补程序分支。
• 这个错误真的很糟糕并阻止了开发分支的其他进展吗？回滚更改。
• 这只是一个外部影响最小的小问题吗？只需继续在功能分支上工作，并在准备好时再次合并。

从 Git 的角度来看，功能分支和错误修复分支之间的区别并不重要。仅当您将这些标签用于内部文档或其他审计目的（例如，跟踪外部用户可见的内容）时才重要。

抵制直接从开发分支开始工作的诱惑，即使您认为错误修复会很快 - 没有任何事情像看起来那么简单，如果出现任何问题，您稍后会让自己头疼。

您选择的粗略视觉表示：

Answer 2

如何找到引入错误的提交，并创建一个新的分支？使用这种方法：

• 由于 rebase 操作，不存在创建损坏引用的风险
• 仅仅从开发分支、特性分支和任何其他可能受到影响的分支的祖先，您就可以知道一旦完成，您应该在哪里合并您的错误修复分支。即使“功能”与“开发”自引入错误以来多次合并也是如此。
• 如果你确定了引入 bug 的提交，并从那里获得 root，开发人员将能够知道他们需要在哪里合并 bugfix 分支，即使他们不熟悉 repo 布局
• 您将拥有一个可以合并的分支，而不必担心引入不相关的后续更改。例如 - 假设有人正在研究“feature-beta”，这是“feature”的一个子分支，在引入错误后不久就出现了分歧。他们可以轻松地拉入错误修复分支，而不必担心还会拉入“功能”上发生的所有其他事情。
• 这种方法减少了樱桃选择的需要，它的缺点是它改变了提交的名称（因此破坏了 git 的一大优势，即对所有内容应用一个明确的名称。）

Answer 3

如果该功能分支是公共分支（即推送到其他人克隆/使用的远程仓库），最好创建一个新分支并将调试隔离在所述修复分支中。
（而不是尝试在 ' feature' 分支之上重新设置 ' develop' 分支）。

这个想法仍然是不直接在develop分支中记录中间调试提交，而是只记录结果提交，该提交将首先修复由feature分支合并引入的错误。

Answer 4

只需创建一个分支（或使用旧的合并feature分支）并在那里修复它。

使用旧分支/创建新分支是一样的——你不能说出合并后哪个是哪个。