功能分支中的错误修复

Question

我们使用Vincent Driessen的A successful Git branching model作为我们的分支模型。一切都很好，但我还没有真正看到一个特定的问题。

根据我的理解，当需要新功能时，您可以分支development并创建一个新的feature分支。您将处理此问题，并在完成后，将此分支合并到development分支中。

如果开发人员创建了一个功能，然后将该功能合并回development，那么只会发现功能代码中存在一些错误。应该在哪里修复？是否应该从开发中启动新的fix / bugfix分支并修复代码？我看不到另一种方式。

应该怎么做呢？

由于

Answer 1

请记住，模型只是一个模型 - 它是为您提供一种结构，使您更有效率，而不是盲目地遵循一套规则。这意味着你应该随意调整一下并找出适用于你情况的东西，因为它可能不适用于所有情况。

我认为你可以选择这种情况：

1. 回滚合并并继续处理功能分支，直到准备就绪
2. 启动新分支以修复错误。

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

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

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

即使您认为错误修复程序非常快，也要抵制直接从开发分支工作的诱惑 - 没有什么比看起来那么简单，如果出现任何问题，您将在以后给自己带来麻烦。

您选择的粗略视觉表现：

Answer 2

finding the commit that introduced the bug, and creating a new branch rooted there怎么样？采用这种方法：

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

Answer 3

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

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

Answer 4

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

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