如何找到版本控制系统中的某些更改？

Question

这里不知道是不是触及了一个微妙的话题，至少看起来并不容易……

那里有很多VCS，还有更多的帖子/博客/...描述了它们的效率。还有很多建议可以在不需要时从代码中删除内容（干净的代码）。总有诸如“它不会迷路”、“你总能找回它”之类的句子，...

我不能完全理解这一点。假设有几个开发人员致力于一个特定的项目。新需求出现在现场，导致创建、修改和删除代码。并希望重构。

实际上，偶尔会发生需要某个功能，然后删除然后重新添加的情况。换句话说，已经编写了代码。该代码是在“必需”阶段编写的，并在“不再”阶段被删除。 “重新添加”阶段会发生什么？有些人可能会建议重写代码，但我不认为这是一个选项。实际上，“旧”代码可能包含对当时出现的问题的修复。

项目不小，类多，逻辑多，可能人事变动，你懂的。恕我直言，总是期望至少一位开发人员记住有代码编写以及发生的位置（包括分支名称）是不公平的。

是否有来自 VCS 的支持来回答诸如

之类的问题

• 一个尚未删除的特定方法在哪里，我对它的名称只有一个模糊的猜测？
• 我很确定这里有一个 if 语句，但它发生了什么？
• ...

我不想将此问题仅限于一个 VCS。这应该是一个更普遍的问题。如果有人关心，我们目前使用 Mercurial。

Answer 1

这是最好处理的场景：

• 许多功能分支
• 您正在合并的一个合并分支（或 reverting，如果您不想再合并某个功能）所有应用于下一个版本的功能，以便执行集成测试。

（如“What is a useful Branch Versioning Strategy?”中所述）

使用 DVCS（Mercurial、Git）更容易做到这一点，因为您可以轻松地将一组提交从一个分支合并/rebase/cherry-pick 到另一个分支，还可以canceling commits you don't want to see。

---

现在关于“寻找东西”：

由于 DVCS 中的修订往往比 CVCS 中的要小，因此您最终会在自己的提交中隔离“小东西”，您可以稍后再回来查看它们是否已合并。

使用 DVCS 更容易的是：

• 使用连贯的更改集保持清晰的历史记录（因为您可以重新安排提交，splitting them or merging 将它们放在一起），这改进了获取在明确识别的提交中隔离的特定修改的更改（并且不与其他更改混合）在同一版本中），
• finding a specific content within commits。