重新格式化和版本控制

代码格式很重要。甚至缩进也很重要。一致性比微小的改进更为重要。但是，项目通常从第一天起就没有清晰，完整，可验证和强制的样式指南，并且重大改进可能会在任何一天出现。也许你发现

SELECT id, name, address
FROM persons JOIN addresses ON persons.id = addresses.person_id;

可以更好地写成/比

SELECT persons.id,
       persons.name,
       addresses.address
  FROM persons
  JOIN addresses ON persons.id = addresses.person_id;

同时在查询中添加更多列。也许这是代码中所有四个查询中最复杂的查询，或者成千上万个简单查询。无论过渡有多困难，您都认为值得。但是，如何跟踪主要格式更改中的代码更改？您可以放弃并说“这是我们再次开始的地方”，也可以重新格式化整个存储库历史记录中的所有查询。

如果您正在使用像Git这样的分布式版本控制系统，则可以还原到有史以来的第一次提交，然后从那里重新格式化为当前状态。但这是一项艰巨的工作，其他所有人都必须在工作进行期间暂停工作（或为所有合并的母亲做好准备）。有没有更好的方法可以更改历史记录，从而获得最好的结果：

• 所有提交中的样式相同
• 最少的合并工作

？

需要澄清的是，这与启动项目时的最佳实践无关，而是在大型重构被视为Good Thing™却又想获得可追溯的历史时应该怎么做？如果这是确保您的版本始终保持相同工作的唯一方法，则永远不要重写历史记录，这是伟大的，但是对于开发人员而言，全新重写的好处是什么？特别是如果您有方法（测试，语法定义或编译后的相同二进制文件）可以确保重写后的版本与原始版本完全一样？

重新格式化为单独的提交。这将对历史的影响降到最低，并且您应该能够一眼看出哪些提交只是重新格式化，哪些实际上更改了代码。它可能会歪斜git blame并且类似，但是如果它指向仅重新格式化的提交，那么在此之前查找先前的更改是相当简单的。

不要重写VCS历史记录：它违反了VCS原则。

不要尝试自动修复格式：它是在处理症状，而不是真正的问题（=开发人员未遵循编码标准）。

在通用文档中定义编码标准和格式化最佳做法，并征得所有开发人员的同意。

您提到了Git，它很棒，因为它是分布式的。使用DVCS，可以通过网守工作流程轻松实施最佳实践。看门人拒绝不符合通用准则的合并建议（= Git中的拉取请求）。我的意思是用粗体字母拒绝，否则违反代码的编码人员将不会理会规则并继续重复同样的错误。

这项技术对我来说效果很好。编码人员希望合并他们的工作，因此在开始时犯了一些错误之后，他们开始遵循规则。

按照固定现有代码库的方式...我建议逐步进行此操作，也许逐个模块进行，或者对您的项目有意义。在每一步都要仔细测试。听起来可能很愚蠢，但是即使进行了微小的更改（例如仅格式化），也确实会发生错误，因此请为路上的一些小事故做好准备。

实际问题的答案是“您不知道”。我不知道当前的SCM工具可以跟踪以一种方式格式化的代码，通过主要的格式化更改以及在以新方式格式化代码后进行的进一步更改而引起的逻辑更改。而且，您知道这一点，丢失一段代码的历史记录是不好的。

因此，我将有点矛盾您的第一句话。代码格式并不重要的是很多。漂亮很好，但这不是我们想要的。与任何人一样，我也了解到，使用两个空格的缩进将其转储到某人的旧的地狱般怪异的K＆R变体代码中很糟糕（1），但是...格式化实际上并不是理解正在发生的事情的障碍，除非有特殊情况病理的。在那种情况下，无论如何您都会遇到更改代码的问题，因此不要理会它。

因此，不宜对现有代码进行严格更改以重新格式化它。更改变量名称，破坏长函数，所有可以改变内容的好的重构内容，是的，但不能重新格式化。

1）-我曾经拥有Windows Clipboard Viewer一段时间。整个过程是一个150k C模块。我发现一个地方，不同的人在30行之间使用了五种不同的花括号样式。但是那部分工作正常。我进行了十年的代码输出，但是我没有戳它，因为历史很重要，并且该代码存在于至少三个都存在的源代码树（Windows 3.x，NT，future 95）中。在不同的建筑物中。

但是，如何跟踪主要格式更改中的代码更改？

格式更改就是代码更改；就像对待代码进行任何其他更改一样对待它们。任何从事重大项目工作的人都可能会看到错误和其他问题，这些错误和其他问题是当某人决定“仅”重新格式化某些代码时产生的。

但这是一项艰巨的工作，其他所有人都必须在工作进行期间暂停工作（或为所有合并的母亲做好准备）。

为什么必须同时重新格式化所有内容？尤其是如果重新格式化不会改变代码的含义，则您应该能够单独重新格式化文件并在进行操作时将其检入。更好的是，让团队中的每个人都同意一种风格（否则无论如何都没有必要重新格式化），并让他们在其他工作中都照顾到重新格式化。一段时间之后，您将覆盖大部分代码，而不会破坏项目的其余部分。

我已经看到了两种可行的方法。

1.重新格式化提交挂钩

虽然最初提交代码后修改代码是很麻烦的，但是如果重新格式化过程（例如astyle）不会损害代码，那么它是安全的操作。随着时间的流逝，整个团队将意识到所有代码最终看起来都是相同的。显然，进行全面的单元/自动测试将确保没有任何损坏。

2.一次性重新格式化所有代码

根据我的经验，这更加危险，并且很难在大爆炸中跟踪问题，但是有可能。之后必须运行所有测试。对于编码样式，大多数差异都围绕空白的使用-缩进或换行。应该能够让一个体面的合并工具忽略所有空白差异，因此这将有助于合并。