您是否将重构更改与功能开发/错误修复更改混合在一起，还是将它们分开？可以使用像Resharper这样的工具执行的大规模重构或重新格式化代码应该与功能工作或错误修复分开，因为很难在修订之间进行差异，并在众多重构更改中查看代码的真正更改。这是个好主意吗？
答案 0 :(得分：5)
当我记得，我想在重构之后检查以准备添加功能。通常，它会使代码处于更好的状态，但不会改变行为。如果我决定退出该功能，我可以随时保留更好的结构化代码。
答案 1 :(得分：3)
保持简单。
每次签入都应该是对代码库的独特，单一，增量更改。
这样可以更轻松地跟踪更改并了解代码发生了什么，尤其是当您发现上个月11日某个地方出现了一个模糊的错误时。试图在一个300个文件的重构签名中找到一个单行更改真的非常糟糕。
答案 2 :(得分：2)
通常，我在完成某些工作单元时检入，并且代码返回到编译/单元测试是绿色的。这可能包括重构。我会说最好的做法是尝试将它们分开。我发现很难处理我的工作流程。
答案 3 :(得分：1)
我同意之前的回复。如有疑问，请将更改分成多个提交。如果您不希望通过大量的小更改来混淆更改历史记录（并将修订版本显示为一个原子更改），请在可以拆分它们的侧分支中执行这些更改。如果每个变化都清晰易懂，那么稍后阅读差异会更加容易（并且可以放心，没有任何事情被无意中破坏）。
在修复格式的同时不要更改功能。如果更改条件的含义以便可以缩进一大堆代码，则在一次更改中更改逻辑并在后续更改中执行outdent。并且明确提交您的提交消息。
答案 4 :(得分：0)
如果源代码控制系统允许它.. （这在我当前的工作中不起作用，因为源代码控制系统不喜欢单个用户将单个文件签出到多个位置。）
因此，每次重构都在自己的签入中，其他开发人员快速获得重构，因此合并问题较少。