重构在GitFlow分支命名模型中属于什么地方？

我最近开始使用由bitbucket实现的GitFlow模型。我有一件事还不完全清楚。

我们试图通过积压，计划和实施重构任务来定期解决我们的技术债务。这样的重构分支以合并到中的拉取请求结束develop。我的问题是重构分支在哪里属于GitFlow？

使用feature前缀似乎是最合乎逻辑的方法，但是感觉并不完全正确，因为重构不会添加任何新功能。
但是，使用bugfix前缀似乎并不正确，因为没有实际的错误重构修复程序。
另一方面，如果不过度设计，则创建自定义前缀看起来很复杂。

你有这种情况吗？您使用哪种做法解决此问题？请解释原因。

— 美国医学会
source

为什么根本需要分支来进行重构？它们不会按照定义改变产品的功能，因此您应该能够直接在开发中进行操作。

— jonrsharpe

简而言之，@ jonrsharpe，它更方便且可控制。通常有一个用于重构的Jira票证，并且在请求请求期间也会对其进行代码审查。此外，在合并之前，会为此运行构建和测试。我们努力使发展分支机构保持绿色。

— AMA

您正在过度设计事物-在这种情况下，就是过程。在系统上工作时重构，而不是作为离散的工作包重构。

— Cochese先生17年

在这种情况下：1.您有我的同情；和2.我会说use refactor，那么很明显，每次合并都将对产品进行什么转换（错误修正：修复损坏的行为，功能：添加新行为，重构：保留以前的行为）。但是@MrCochese是正确的，它确实应该是您正在执行的其他工作的一部分，而不是单独的任务。另请注意，如果您的重构破坏了构建，则它们不是重构！

— jonrsharpe

您正在进行的一些重构工作实际上应该是主要工作的一部分。我当然不会常规地进行重构分支，而只是作为更大清理工作的一部分。养成这种习惯会鼓励其他不良习惯，例如将清理工作推迟到“重构”分支。

— 罗伯特·哈维

重构工作应该在功能分支中进行。

前缀“功能”只是一个单词，用于描述离散的编程任务，您可以选择任何喜欢的单词，开发中的任何分支都是“功能”分支或“发行”分支

添加诸如“重构”之类的新前缀是有问题的。由于添加功能时经常会进行一些重构，因此您只是在给自己一个命名问题，并增加了混乱。即。“我们的某些功能分支称为“重构”，不，它们不包含所有重构工作，有时它们中包含错误修复或功能。”

同样，“修补程序”分支不称为修补程序，因为它们包含修补程序，而是因为它们是从母版而不是从开发分支出来的

— 伊万
source

谢谢。听起来很合理。我会再等一会，如果没有其他答案，我会接受您的回答。

— AMA