功能分支中的错误修复

Question

我们使用Vincent Driessen 成功的Git分支模型作为我们的分支模型.一切都很好,但我还没有真正看到一个特定的问题.

根据我的理解,当需要新功能时,您可以分支development并创建一个新feature分支.你会在这方面工作,当你完成后,你会将这个分支合并到development分支中.

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

应该怎么做呢？

谢谢

Answer 1

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

我想你在这种情况下有一个选择:

1. 回滚合并并继续处理功能分支,直到它准备就绪
2. 启动一个新分支来修复bug.

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

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

从Git的角度来看,功能分支和bugfix分支之间的区别并不重要.如果您使用的内部文件或其他审计目的的标签(例如跟踪什么是可见的外部用户),唯一要紧的.

即使您认为错误修正将非常快,也要抵制直接从开发分支工作的诱惑 - 没有什么比看起来那么简单,如果出现任何问题,您将在以后给自己一个头痛.

您选择的粗略视觉表示:

Answer 2

如何找到引入错误的提交，并在那里创建一个新分支？通过这种方法：

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