不立即从VCS中删除冗余文件，而是先将它们标记为“待删除”，这是不好的做法吗？

我想知道我处理需要从版本控制中删除的源文件的方式是否被视为不良做法。

我想根据该示例向您解释：

最近我非常生气，因为我必须在程序中将Java类繁琐地整理出来，这些类基本上是无效的代码，但是在这些Java类中都没有文档记录和注释。当然，需要删除它们，但是在删除这些多余的东西之前，我有一个-有些人可能说奇怪-习惯：

我不会立即通过SVN-> Delete（用您选择的版本控制系统的delete命令替换）来删除这些冗余文件，而是将注释放置在这些文件中（这些文件的开头和结尾处都是引用）被删除+我的名字+日期，以及-更重要的是- 为什么被删除（在我的情况下，因为它们已经死了，代码令人困惑）。然后保存并提交给版本控制。下次当我必须在项目中提交/签入版本控制时，我按SVN-> Delete，然后最终将它们在版本控制中删除-当然仍然可以通过修订来恢复，这就是为什么我采用了这种习惯。

为什么要这样做而不是立即删除它们？

我的理由是，我至少要在存在那些冗余文件的上一个修订版本中要有显式标记，为什么应该删除它们。如果我立即删除它们，它们将被删除，但是没有地方记录为什么删除它们。我想避免这样的典型情况：

“嗯...为什么删除了那些文件？我以前工作得很好。” （按“还原”->还原然后再消失的家伙将在下个星期永远消失或不可用，下一位受让人必须像我一样单调乏味地找出这些文件的内容）

但是您没有注意到为什么这些文件在提交消息中被删除了吗？

我当然可以，但是同事有时看不到提交消息。在您试图理解（在我的情况下为死机）代码时，首先使用所有关联的提交消息检查版本控制日志的情况并不常见。与其查看日志，不如立即看到该文件无用。这样可以节省她/他的时间，并且她/他知道此文件可能已恢复为坏文件（或至少引起了一个问题。）

将注释添加到应删除的文件而不是将其删除到源代码管理中并在其中进行解释的问题是，假设开发人员不阅读提交消息，他们肯定会阅读源代码中的注释。

从局外人的角度来看，这种方法似乎植根于非常保守的源代码管理观点。

“如果我删除了这个未使用的文件而又有人需要它怎么办？” 有人可能会问。

您正在使用源代码管理。恢复更改，或者最好与删除该文件的人联系（进行交流）。

“如果我删除无效文件，然后有人再次使用它并进行更改，该怎么办？” 别人可能会问。

同样，您正在使用源代码管理。您将遇到一个人必须解决的合并冲突。与最后一个问题一样，这里的答案是与队友交流。

如果您确实怀疑应该删除文件，请先进行沟通，然后再从源代码管理中删除它。也许它只是最近才停止使用，但是即将发布的功能可能需要它。您不知道，但是其他开发人员之一可能会。

如果应将其卸下，请将其卸下。从代码库中删除胖子。

如果您做了“ oopsie”，但实际上需要该文件，请记住您正在使用源代码管理，以便可以恢复该文件。

文森特·萨瓦德（Vincent Savard）在对问题的评论中说：

...如果您的同事没有阅读提交消息，而是让他们复活了正确删除的文件并通过了代码审查，则您的团队肯定存在问题，这是一个很好的机会来教他们更好的机会。

这是合理的建议。代码审查应该抓住这种事情。当对文件进行意外更改或删除或重命名文件时，开发人员需要咨询提交消息。

如果提交消息没有说明问题，那么开发人员还需要编写更好的提交消息。

害怕删除代码或删除文件表示该过程存在更深层次的系统性问题：

• 缺乏准确的代码审查
• 对源代码管理的工作原理缺乏了解
• 缺乏团队沟通
• 开发人员的提交信息不佳

这些是要解决的问题，因此，删除代码或文件时，您不会觉得自己在玻璃屋子里扔石头。

是的，这是不好的做法。

提交文件删除时，应在提交消息中放入有关删除的说明。

在源文件中的注释应该解释代码，因为它目前看起来。提交消息应解释为什么要进行提交更改，因此文件上的提交历史记录说明了其历史记录。

直接在源代码本身中编写注释来解释更改，只会使代码难以遵循。想想看：如果您每次更改或删除代码时都在文件中添加注释，则很快该文件将充满有关更改历史记录的注释。

我认为，相对于不良做法，您的两个选择都不是最佳做法：

1. 如果有人碰巧阅读了这些评论，则添加评论只会增加任何价值。
2. 简单地从VCS中删除（在变更说明中有其原因），可能会影响关键的交付成果，并且许多人不会阅读变更说明，尤其是在承受压力的情况下。

我偏爱的做法（主要是由于多年来被多次咬伤，并记住您并不总是知道在哪里或在哪里使用您的代码）是：

1. 添加一条注释，说明它是删除和弃用 #warning 或类似print的候选对象（大多数语言都有这种机制，例如在Java中，在最坏的情况下，一条语句或类似的词就足够了），理想情况下，它具有某种时标和以及联系方式。这将警告仍在实际使用该代码的任何人。这些警告通常存在于每个函数或类的内部（如果存在）。
2. 一段时间后，将警告升级到标准文件范围#warning（某些人会忽略弃用警告，并且某些工具链默认情况下不显示此类警告）。
3. 以后#warning用a #error或等效项替换文件作用域-这将在构建时破坏代码，但是，如果绝对必要，可以将其删除，但是删除该文件的人员不能忽略它。（有些开发人员没有阅读或处理任何警告，或者警告太多，无法将重要警告分开。）
4. 最后，将文件（在到期日或之后）标记为已在VCS中删除。
5. 如果在警告阶段删除整个程序包/库/等，我将添加README.txt或README.html或类似内容，以及有关计划何时，为何计划删除程序包并仅保留该文件的信息，并带有一个改为说删除它的时间，因为在删除其余内容后一段时间内该包是唯一的内容。

这种方法的一个优势是，某些版本控制系统（CVS，PVCS等）在签出时不会删除现有文件（如果已在VCS中将其删除）。它还为有责任心的开发人员，解决所有警告的人员提供了大量时间来解决问题或对删除提出上诉。它还迫使其余的开发人员至少要查看删除通知并抱怨很多。

请注意，#warning/ #error是一种C / C ++机制，当编译器遇到该代码时，它会引起警告/错误，随后是所提供的文本，java / java-doc具有@Deprecated注释，以在使用时发出警告并@deprecated提供一些信息，等等。在python中做类似的食谱＆我见过assert用来提供与#error现实世界类似的信息。

是的，我会说这是一种不好的做法，但不是因为它在文件中而不是在提交消息中。问题是您试图在不与团队沟通的情况下进行更改。

每当您对主干进行任何更改（以任何方式添加，删除或修改文件）时，您都应在提交回主干之前，直接与将直接联系团队的一个或多个团队成员讨论这些更改。了解他们（本质上，直接与队友讨论您将在这些标题中放入什么）。这将确保（1）您确实要删除的代码确实需要删除，并且（2）您的团队更有可能知道该代码已删除，因此不尝试还原您的删除。更不用说您还将获得所添加代码的错误检测之类的东西。

当然，当您更改重大内容时，也应该将其放入提交消息中，但是由于您已经讨论过它，因此它不必成为重要声明的来源。史蒂夫·巴恩斯（Steve Barnes）的答案还解决了一些潜在的好策略，如果您的代码的潜在用户池太大（例如，使用您语言的不推荐使用的标记，而不是首先删除文件）。

如果您不想花那么长时间不提交（即，您的更改作为多个修订版本最有意义），最好从主干创建一个分支并提交到该分支，然后在分支完成时将其合并回主干。更改已准备就绪。这样，VCS仍会为您备份文件，但是您的更改不会以任何方式影响中继。

一个基于多个平台和配置的项目的相关问题。仅仅因为我确定它已经死了并不意味着它是正确的决定。请注意，停止使用仍然可能意味着残留的依存关系，仍然需要清除，有些可能已经遗漏了。

所以（在一个C ++项目中）我添加了

#error this is not as dead as I thought it was

然后签入。等待它完成所有正常平台的重建，并且没人抱怨它。如果有人找到了它，那么很容易删除一行，而不会因丢失文件而感到困惑。

原则上，我同意您提到的评论与版本管理系统中应做的功能重复。但是，您可能有特定的理由对此进行补充。不知道VCS工具不是其中之一。

在不良实践的连续性上，这是相当小的。当我想签出一个分支并能够看到旧代码时，我有时会这样做。这可以简化与替换代码的比较。我通常会收到一个代码审查注释“ cruft”。稍加解释，我就通过了代码审查。

但是这段代码不会持续很长时间。我通常在下一个Sprint的开头删除。

如果您的同事不阅读提交消息或不问您为什么将代码留在项目中，那么您的问题就不是不好的编码风格之一。您有其他问题。

您还可以重构类，并在拉动特技之前使用UNUSED_Classname前缀对其进行重命名。那你也应该直接提交删除操作

• 第1步：重命名课程，添加评论，提交
• 步骤2：删除文件并提交

如果是无效代码，请将其删除。任何人都需要它，他们可以返回，但是重命名步骤将阻止他们直接使用它而无需考虑。

还教人们如何查看文件的所有提交消息，有些人甚至不知道这是可能的。