在功能分支上工作时应提高代码质量吗

我真的很喜欢这篇文章，它使代码/营地处于比您发现的状态更好的状态 -在现实世界中，保持代码整洁似乎是一种实用的方法。

我也非常喜欢要素分支，它是一种独立开发要素的方法，这样，如果您不喜欢它，就可以轻松地将其合并等。

但是，如果我在功能分支上工作，并且发现一些难看的代码，是否应该解决它？

感觉有很多缺点需要解决：

• 当我将分支合并回去时，差异将变得混乱，变量重命名或函数提取会变得混乱
• 如果放弃了该功能，则必须选择清除提交（根据其附近的代码如何进行混乱的合并而改变可能有效或无效），重新执行或放弃它。

另一方面，如果我在文件中时不执行此操作，那么很明显，我会在合并分支的几天之内忘记执行此操作。

我被警告说这是基于观点的（我认为标题仅包含事实should），但是我觉得有一个答案（肯定有人使用这两种方法，所以他们必须有答案）。此外，有关的问题development methodologies都是话题，我认为它们需要一定的意见。

如果您无论如何都将代码片段作为功能的一部分进行更改，则仅应在功能分支中“修复”代码。

例如。我正在使用“打印兔子”功能，并且找到了打印机代码

Public class Printer(string type)
{
    If(type=="bunnies")
    {
        //print a bunny
    }
.....
}

我将其更改为：

Public class Printer(string type)
{
     PrintFunctionDictionary[type].Print();
}

为什么：

• 我正在编写代码，
• 我需要对其进行更改以添加功能，
• 增加的功能建议采用重构方法来解决该问题。

我不会随机访问代码库的其他部分并“使其变得更好”，因为这会：

• 与使用其他功能的人发生冲突。
• 使用时间应分配给开发功能。
• 向分支添加任意代码，如果该功能尚未完成，则可能不会合并到主产品中。同样，如果我回滚功能，我将失去重构。

如果您希望重构从当前功能分支“独立进行”，请不要在那里进行更改。而是在主开发分支（或“重构分支”，如果在团队中很常见，不要直接将更改直接应用于dev分支）上进行重构。因此，您团队中的任何人（包括您）都可以将更改合并到他们正在使用的活动功能分支中。但是，请注意不要在整个“代码库的一半”中应用任何全局重构，而无需先征得同事的许可-如果重构对他们当前的工作造成太大干扰，他们可能不会很高兴。

当您所做的改进完全位于您在该功能分支中接触的部分代码库本地，并且为它们赋予与“新功能”不同的生命周期时，这是没有道理的。

branch类型的目的是提供处理它们的意图。如果你下面分支的GitFlow风格，那么你有可能喜欢的类型feature，hotfix，release，等。在一个特性分支的情况下，它的意图是封装合并到另一个分支（即develop），显示了开发商负责合并，此功能是什么。如果您要清除的代码不属于该功能，请不要更改它。

相反，找到丑陋代码所在的最低可能分支（可能是develop），然后从那里分支。更改代码并建议将其合并为功能。如果您在工作中需要该代码，特别是想避免合并冲突，请将该分支合并到您的分支中。

这是不同策略的一个很好的解释：https : //www.atlassian.com/git/tutorials/comparing-workflows/

如果我在功能分支上工作，并且发现一些难看的代码，我应该解决它吗？

根据项目的速度，代码的“丑陋性”等，将“丑陋的代码”固定在视线范围内可能很好，但是请不要在功能分支本身上执行此操作。

• 如果您的功能分支完全位于本地，则仅存储或提交未保存的更改，请签出开发分支，进行更改，然后返回到功能分支并以开发为基础。
• 如果您不能以开发为基础（例如，功能分支位于公共服务器上），则仍然可以在需要时选择取消开发，也可以避免以后发生冲突。
• 如果您正在编辑文件，并且确实必须立即将修复程序提交给丑陋的代码，而实际上却不能切换到开发状态，则可以进行修复，使用git add -p进行修复，仅提交更改，然后再合并/推送（实际上，最好是在下一次提交之后），根据您的历史记录，使用交互式变基将提交移至分支中最早的位置，甚至可以选择进行开发。

我还将使用“修复”开发分支的其他任何方法（其中“修复”是您或任何其他开发人员可能会看到的更改，以确保代码符合标准）。这有帮助...

• 以便将您的修订和功能提交到不同的组中，以便使日志更加可读，
• 保持开发尽可能接近可发布的状态，并且
• 避免重复工作（多个人在不同分支机构以不同的方式解决同一问题）。