version-control - 如何在版本控制系统中找到某些更改？

Question

不知道这里有没有触及敏感话题，至少看起来并不容易……

有很多VCS在那里，有更多的帖子/博客/...描述它们的效率。还有很多建议可以在不需要时从代码中删除内容(干净的代码)。总有这样的句子“无论如何都不会迷路”，“你总是可以回到它”，......

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

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

项目不小，类(class)多，逻辑多，也许人事变动，你懂的。恕我直言，总是期望至少有一位开发人员记住代码是写过的以及代码发生的地方(包括分支名称)是不公平的。

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 .