svn - 一些基本的版本控制问题

Question

...我不想分成几个问题帖子，因为我猜，它们是基本的，这里的大多数人都会知道如何回答。

我已经开发了好几年了，但从来没有时间学习版本控制。重命名具有不同版本名称的目录似乎总是足够了。现在，我终于决定学习它了，但一些基本的术语和工作原理仍然让我感到困惑。

我的项目比较小，最多10个左右的文件(虽然文件比较大)，而且是非OO方式完成的。我经常采用一种方法，做到一定程度，然后决定不行，然后(重用旧代码)用完全不同的文件组织和内部代码组织完全重写整个项目。在这些“版本”之间出现文件消失和新文件的情况并不少见。

所以这是我的“困惑”:
1)例如，如上所述，我已经将第一个版本放入了vc。然后我删除所有文件，并重新写入它们。如果我理解得很好，那将是一个新的“分支”，对吧？
2) 如果我继续开发那个版本，我会一直致力于那个“分支”吗？
3)vc在保存分支中的保存点时，保存所有文件，还是只保存它们之间的差异？
4)我可以轻松地从分支中的某个保存点获取所有(整个项目)文件，还是我必须通过 diff 跟踪它直到开始？ (我只想说，“在这里，这是保存点 - 复制你需要的所有文件，所以它看起来像这样”)
5)用非常简单的术语来说，“推”和“pull ”是什么意思。我不明白“推”/“pull ”和“提交”之间的区别。

如果重要的话，我正在使用 VS 2008，并且正在考虑使用 git-extensions，因为我听说过有关它的好消息。考虑到上述情况，它是一个很好的组合吗？使用 SVN(例如 VisualSvn 或 Ankh)对我来说是更好的选择吗？

-- 带着敬意， 彼得

Answer 1

您的部分困惑可能来自使用不同术语的不同版本控制系统 (VCS)。

我通常以“行”的形式来考虑代码。我从文件的原始版本开始，并将其保存到我的版本控制系统中。将其放入 VCS 称为“ checkin ”。版本控制系统用一些数字标记它，例如修订版 1.0。现在我编译我的软件。它坏了，所以我必须编辑它。为此，我从版本控制系统“检查它”并对其进行编辑。现在它已修复，我将其重新 checkin ，版本控制系统将其存储为修订版 1.1。我的老板想要一个新功能，所以我 checkout 它，编辑它，然后再次 checkin ，它被存储为修订版 1.2。

这是代码的“主线”或“主干”。

版本控制系统可以让您通过指定修订号来获取文件的任何旧版本。假设我从基于修订版 1.1 的软件中获得错误报告。我可以使用“diff”或任何比较工具来比较 1.1 和 1.0，看看有什么变化。版本控制系统如何在内部存储它并不重要，我只需通过修订号请求它，我就会得到整个文件。

接下来要了解的是，一组文件构成了您的项目或解决方案。当您要编译您的软件以将其发布到全世界时，您希望将一个“标签”与所有这些文件相关联，以便您可以将它们视为一个整体。大多数人使用数字标签，例如 Windows 3.0、Windows 3.51 等，但这只是约定俗成。如果需要，您可以将一个版本标记为“hardy heron”或“gutsy gibbon”。

现在，如果您是一个不断更新内容的人，这一切都很好。但是假设您继续开发您的软件，发布版本 7，然后是 8，然后是 9，现在您正在开发版本 10。但是今天您收到关于版本 7 的严重错误报告，您只需要修复它。因此，您转到 VCS 并请求所有带有“版本 7”标签的源文件。您将它们放入磁盘上的单独文件夹中，并修复错误。但是当您 checkin 这些文件时，您需要它们成为版本 7 的一部分，因为您已经在版本 8 和 9 中添加了功能。这是您创建“分支”的时候。

举个例子可能更清楚。假设您检查了包的“版本 7”，而要修复的文件是修订版 1.23。在版本 10(您在不同的文件夹中处理)中，您使用的是修订版 1.40。您不希望版本 7 的更改进入 1.41，因为这会覆盖并破坏您在修订版 1.24 到 1.40 中添加的所有简洁功能。因此，您创建了一个分支，并将更改后的文件作为修订版 1.23.0.1 checkin 。您编译它，现在错误已修复。现在您必须将它发布给您的客户。发布时，您创建了一个新标签。我将其标记为“7.1 版”，这样我就可以区分损坏的软件和修复后的软件。而且我知道它不具备版本 8+ 的所有功能。

如果将这些软件版本绘制在一条线上，您会想到一条从 1 到 10 的数字线。7.1 适合这条线的什么位置？它从侧面伸出来，就像 Twig 从树干上伸出来一样。这就是我们从中获得“分支”和“主干”名称的地方。