软件重构的版本控制

Question

对大规模重构进行版本控制的最佳方法是什么？

我的典型编程风格（实际上也是编写文档）是尽快得到一些东西，然后重构它。通常，重构与添加其他功能同时进行。除了对类和函数进行标准重构之外，函数可能会从一个文件移动到另一个文件，文件会被拆分和合并或只是重新排序。

目前，我作为一个单独的用户使用版本控制，所以在这个阶段与其他开发人员交互没有问题。不过，版本控制给了我两个方面：

1. 备份和“以防万一”恢复到良好版本的能力。
2. 回顾历史可以告诉我项目的进展情况和想法的流动。

我正在使用 TortoiseHg 在 Windows 上使用 mercurial，它可以选择提交的帅哥。我提到这一点的原因是我想就重构中的提交粒度提出建议。我应该将重构与提交时添加的功能分开吗？

我查看了Refactoring and Source Control: How To? 的答案，但它没有回答我的问题。该问题侧重于与团队的协作。这个专注于拥有未来可以理解的历史（假设我不会像某些 VCS 允许的那样重写历史）。

Answer 1

我想没有一个适合所有问题的答案:)
就个人而言，我更喜欢在我的提交中保持更精细的合理粒度：在你的情况下，我会将操作分为两个阶段：每个阶段都是独立的：

1. 重构（和后续提交）
2. 新功能（和提交）。

最好的做法是单独添加和提交每个项目：将重构分解为本地化更改，并一项一项提交，并一项一项添加功能，一路提交。

有更多的开销，但是通过这种方式，当您回过头来寻找差异时，重构和添加新功能的变化是很清楚的。仅回滚特定有问题的添加也更容易。

Answer 2

我应该将重构与提交时添加的功能分开吗？

我倾向于经常签到；每次签入要么是重构，要么是新功能。这是一个循环：

1. 重构现有代码（不更改其功能），使其准备好接受新代码
2. 添加新代码（实现附加功能）。

Answer 3

我建议将重构与添加功能分开。也许通过交替签到。这是我在发现 uncrustify 后的经验，它会重新格式化源文件，同时还会更改代码。从重新格式化中找出真正的变化变得非常困难。现在 uncrustify 有自己的专用提交。

Answer 4

在解决了非常复杂的重构带来的影响/错误/副作用以及相当广泛的更改之后，我强烈建议您始终尽可能地将两者分开，尽可能地进行版本控制。

如果有任何问题，您可以非常轻松地从与每个阶段相关的标签/标签/版本重新构建代码，并验证两者中的哪一个引入了问题。

此外，尽量在逻辑上完整的块中进行重构，并将它们作为单独的检查点提交。同样，这简化了对什么原因/何时发生故障的调查。

Answer 5

到目前为止，每个答案都建议您将重构与添加功能分开 - 我将它们全部 +1。您应该这样做，独立于源代码控制。 Martin Fowler 围绕您不能在更改功能的同时重构这一概念写了一整本书。您想知道，对于任何更改，代码应该和是否在更改之前和之后的工作方式相同。正如@Amardeep 指出的那样，如果通过格式化或重构更改隐藏了您所做的功能更改，则更难看到您所做的功能更改，因此更难以追踪功能更改引入的错误。我的意思不是要阻止您重构或推迟重构。无论如何，经常这样做。但单独与功能更改分开。微提交是要走的路。

Answer 6

• 迈出小步。做出最小的有用更改、测试、提交并重复。

• 一次改变一种。不要重构和改变行为 同一时间。

• 经常提交。带有清晰、详细描述的小改动非常宝贵。

• 确保您的自动化测试可靠且有用。如果您可以信任您的测试，则可以轻松快速地完成上述操作。

• 确保您的测试始终通过。

我通常会开始研究新功能或错误修复或其他任何东西，以发现如果我只是这样重构，新功能将更容易添加。通常我会丢弃（或保存在其他地方）我到目前为止的更改，重构/测试/提交，然后返回使用新功能。理想情况下，我将 90% 的时间用于重构，每个新功能、错误修复、性能改进等都是简单的单行更改。