功能分支中的错误修复

我们使用Vincent Driessen的A successful Git branching model作为我们的分支模型。一切都很好，但我还没有真正看到过一个特别的问题。功能分支中的错误修复

从我所了解的情况来看，当需要一个新功能时，您需要分支development并创建一个新的feature分支。您可以在此完成，当您完成后，您会将此分支合并到development分支中。

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

应该怎么办？

感谢

2011-08-30 Mridang Agarwalla

我似乎以创建您的问题的副本，但在我的问题中，我采取了提供命令来创建实验回购测试概念的方法：http://stackoverflow.com/questions/32244693/changes-on-feature-分支合并到母版/ 32244878？noredirect = 1＃comment52371049_32244878 您介意我是否用范例回购扩展您的问题，并看看如何将建议的答案实际应用于该回购以及结果如何？ – TheMeaningfulEngineer

请记住，模型只是一个模型 - 它是关于给你一个结构，使你更有效率，而不是盲目遵循一组规则。这意味着你可以随意调整事物并找出适合你的情况，因为它可能在任何情况下都不起作用。

我认为你必须在这种情况下一个选择：

回滚合并，并继续关注的分支工作，直到它准备
开始一个新的分支，以修复bug。

你选择哪一个取决于类似因素：

你的客户可以看到错误？制作修补程序或修补程序分支。
错误是否真的很糟糕，并阻止开发分支的其他进展？回滚更改。
它只是一个小问题，对外部影响最小？只需继续使用功能分支，并在准备就绪后再次合并。

从Git的角度来看，功能分支和bugfix分支之间的区别并不重要。如果您将这些标签用于内部文档或其他审核目的（例如跟踪外部用户可见的内容），那么这一点很重要。

即使您认为bug修复速度非常快，您也可以抵制开发分支的工作 - 任何事情都不会像看起来那么简单，而且如果出现任何问题，您将会很头痛。您的选择

粗糙的可视化表示：

State machine diagram of choices

来源

2011-08-30 06:33:34

如果该功能分支为一公共（即被推到克隆远程回购/被他人使用），最好是做一个新的分支，并在隔离调试说修复分支。
（而不是试图在'develop'分支上重新分配'feature'分支）。

该想法仍然不直接在develop分支中记录中间调试落实，而是仅记录最终提交，它将首先解决feature分支合并引入的错误。

来源

2011-08-30 05:56:32 VonC

只需创建一个分支（或使用旧的，合并的feature分支）并将其修复。

使用旧的分支/创建新的分支是一样的---你不能命名哪个是合并后的。

来源

2011-08-30 06:08:28

如何finding the commit that introduced the bug, and creating a new branch rooted there？使用这种方法：

有没有创造由于变基操作
单从开发分支，特性分支和其他分支可能会受到影响的祖先破引用的风险，你可以告诉哪里一旦完成，你应该合并你的bugfix分支。即使“特征”自引入错误以来多次与“开发”合并，情况也是如此。
如果您确定引入该错误的提交以及来自那里的root，开发人员将能够确定他们需要合并bugfix分支的位置，即使他们不熟悉回购布局
您会有一个分支，你可以合并，而不用担心拉入不相关的后续变化。例如，假设有人正在研究“功能-β”，这是“功能”的一个子分支，在引入错误后不久就分歧了。他们可以轻松地引入bugfix分支，而不必担心引入“feature”上发生的其他任何事情。
这种方法减少了需要摘樱桃，它有它改变提交的名称下跌（从而破坏了Git的巨大优势之一，其应用了明确的名称的一切。）

来源

2012-05-17 22:14:35 gcbenison

+1000。我也认为这是最可取的方法。它导致了非常明确的提交历史记录。另一方面，樱桃采摘是最不透明的方法，因为它完全隐藏了引入臭虫的位置和固定位置。还要注意，git bisect在寻找引入错误的提交方面有很大的帮助。肯定是一个高度建议的方法。 –

功能分支中的错误修复

回答

相关问题