保留版本控制提交历史记录与重构和文档

使用版本控制系统维护的提交历史记录几乎不需要花费任何费用。但是，在大型项目重构（或重组/清理）过程中，函数和类甚至命名空间将被移动；有时，几个文件将合并在一起，而其他文件将被拆分。这些更改通常会导致丢失一些文件的原始提交历史记录。

我个人认为，维护项目组织比保留源代码历史更为重要。优秀的项目组织可以合理地不断添加新功能，而源代码历史记录的价值似乎是可疑的。

此外，通过使用单元测试，可以快速确定回归问题。只要最新版本继续满足所有软件要求，我们是否真的需要保留源代码的历史记录？

我了解必须保留所有已发布的源代码，因为需要向客户提供支持，而无需他们执行主要版本升级。但是除此之外，保持源代码提交历史还有任何价值吗？

源代码提交历史记录是否在团队成员之间的通信中发挥任何作用？如果我们取消提交历史记录，而是依靠“源代码” +“单元测试代码”进行通信，该怎么办？

提交历史的存在是否使对有关该项目的重要信息的长期记录感到满意，例如重大的设计/需求变更以及推动这些变更的思路？

要将提交历史记录用于“所作的更改”或“已修复的错误”类型注释之外，应将其与问题跟踪系统链接。每次更改，每次提交都应该有一些相关的问题，以便您知道更改的内容，更改的对象和原因。

只要最新版本继续满足所有软件要求，我们是否真的需要保留源代码的历史记录？

足够复杂的软件很少会出于多种原因实现所有要求并修复所有错误，因此，我认为您的主张是乐观的。

假设您使用的程序是7.8版。但您在现场支持12个不同的活动版本，例如1.6、2.2、2.8等。由于种种原因，每一个都不会升级到最新版本，因此您将通过错误修复来支持所有这些。客户发现您最新的7.8版本中的错误。您在7.8中进行了修复。您如何知道还有多少其他版本需要修复？没有源历史记录和问题跟踪，您就没有。

源代码历史记录的价值似乎令人怀疑。

我有工程师追溯到几十年前进入源代码寻找答案，为什么事情是这个样子。有时，事物随着时间的发展方式对于理解错误很重要，但是在记录事物时（甚至不一定要记录），通常不会想到它。

同样，保留源代码历史记录可能有很好的法律理由。我必须做的大多数源代码垃圾转移工作（作为一名构建/ SCM工程师）都是应我公司法律部门的要求进行的。

只要最新版本继续满足所有软件要求，我们是否真的需要保留源代码的历史记录？

但是除此之外，保持源代码提交历史还有任何价值吗？

双方都同意。了解何时更改了什么，由谁以及为什么进行更改可能很有用。如果您丢失了历史记录，则执行此操作的能力将受到影响。

源代码提交历史记录是否在团队成员之间的通信中发挥任何作用？如果我们取消提交历史记录，而是依靠“源代码” +“单元测试代码”进行通信，该怎么办？

是的，它确实。仅“源代码” +“单元测试代码”的方法不会告诉您谁/何时/为什么。

提交历史的存在是否使对有关该项目的重要信息的长期记录感到满意，例如重大的设计/需求变更以及推动这些变更的思路？

我想你可以这么说。但是很少有开发人员能够彻底记录需求/设计的变更。毫无疑问，几乎没有人记录推动最初开发或后续修改的思路。具有提交历史记录（尤其是提交日志消息）以及到问题/错误跟踪系统的交叉链接至少可以为您提供帮助。总比没有好，或者有一组发行快照总比没有好。