为什么要使用版本控制？[关闭]

我在读一个博客，作者说

“除非将代码签入版本控制系统，否则代码是不存在的。将版本控制用于您所做的一切。任何版本控制，SVN，Git甚至CVS都可以对其进行掌握和使用。”

我从未使用过任何形式的版本控制，但我认为它并不那么出色。我曾经用谷歌搜索过它，并对其进行了研究，但是如果您愿意的话，我只需要把它放入儿童的语言中即可。

据我目前所了解，诸如SVN之类的东西是用于在线存储代码的，以便一组用户或其他开发人员可以访问相同的代码。更新某些代码后，您可以提交新版本，并且SVN会保留旧代码以及您更新的新代码的副本。

这是它的基本思想还是我完全理解错误？

如果我是对的，那么如果我：

• 不要让其他人来编写代码。
• 不要计划让别人拥有代码。

你有没有：

• 更改了代码，意识到这是一个错误，想还原吗？
• 丢失代码或备份太旧？
• 是否必须维护一个产品的多个版本？
• 是否想查看代码的两个（或多个）版本之间的区别？
• 是否想证明某个特定更改破坏或修复了一段代码？
• 是否想查看一些代码的历史？
• 是否要提交对他人代码的更改？
• 想共享您的代码，还是让其他人使用您的代码？
• 想知道正在完成多少工作，在哪里，何时以及由谁进行？
• 是否想尝试一项新功能而不干扰正常工作的代码？

在这些情况下，毫无疑问，在其他情况下，版本控制系统应使您的生活更轻松。

错误引用朋友的话：文明时代的文明工具。

即使您独自工作，您也可以从源代码管理中受益。其中，由于以下原因：

• 你什么都不会丢失。我再也没有注释掉代码。我只是删除它。它不会使我的屏幕混乱，也不会丢失。我可以通过签出旧提交来恢复它。

• 您可以随意进行实验。如果仍不能解决问题，请还原它。

• 您可以查看以前的代码版本，以了解何时何地引入了错误。git bisect在这方面很棒。

• 诸如分支和合并之类的更多“高级”功能使您可以进行多条并行开发。您可以同时使用两个功能，而不会受到干扰，并且来回切换也没有太多麻烦。

• 您可以看到“更改内容”。这听起来很基础，但是我发现自己经常检查这一点。我通常以一个人的工作流程开始：昨天我做了什么？

只是继续尝试。从基本功能开始慢慢学习，并随手学习其他功能。您很快就会发现，您再也不想回到没有VCS的“黑暗时代”了。

如果需要本地VCS，则可以设置自己的Subversion服务器（我过去所做的事情），但是今天我建议使用git。简单得多。只需cd进入您的代码目录并运行：

git init

欢迎来到俱乐部。

版本控制是一种罕见的工具，即使您只是将其用作单独的开发人员，我也会说它绝对是必需的。有人说，这是您赖以生存和生存的工具，我同意这一主张。

您可能现在就使用版本控制，即使您不知道它。您是否有任何文件夹显示“ XXX Php Code（十二月）”或“ XXX.php.bak.2”？这些已经是版本控制的形式。一个好的版本控制系统将自动为您解决此问题。您将能够回滚到任何时间点（已签入数据），并且能够看到该数据的精确副本。

此外，如果您采用Subversion之类的系统，并使用远程存储库（例如您拥有的服务器上的存储库），则将有一个地方来保存所有代码。需要其他地方的代码副本吗？没问题，只需检查一下即可。硬盘在家崩溃？没问题（至少与您的源代码有关）。

即使您现在不使用版本控制，您也可能会在职业生涯的某个时间点使用它，并且可以从现在更加熟悉这些原则中受益。

甚至一个人工作，这曾经发生过吗？您运行您的应用程序，但没有任何效果，并且您说“昨天有效，我发誓我没碰过那个课程/方法”。如果您定期检查代码，则快速版本差异将准确显示前一天发生的更改。

即使您单独工作，这种情况也可以说明源代码管理的有用性。

您的客户要求您对网站进行雄心勃勃的修改。这将花费您几个星期的时间，并且涉及到对许多页面的修改。你上班了

当客户致电并告诉您放弃正在做的紧急事情，但对站点进行的更次要的更改时，您已经完成了50％的任务。您还没有完成较大的任务，因此它还没有准备就绪，客户无法等待较小的更改。但是他还希望将较小的更改合并到您的工作中，以进行较大的更改。

也许您正在包含网站副本的单独文件夹中处理大型任务。现在，您必须找出如何以可以快速部署的方式进行较小的更改。您会疯狂地完成工作。客户端以进一步的细化请求回叫。您也可以这样做并部署它。一切都很好。

现在，您必须将其合并到正在进行的主要变更中。您为紧急工作做了哪些更改？您工作太快，无法记笔记。而且，由于这两个目录都相对于从其开始的基准进行了更改，因此您不能轻松地对这两个目录进行比较。

上面的场景表明，即使您独自工作，源代码控制也可能是一个很好的工具。

• 您可以使用分支来执行长期任务，然后在完成后将分支合并回主行。
• 您可以将整个文件集与其他分支或以前的版本进行比较，以了解有什么不同。
• 您可以跟踪一段时间内的工作（顺便说一下，这非常适合报告和开具发票）。
• 您可以根据日期或定义的里程碑恢复任何文件的任何修订。

对于单独工作，建议使用Subversion或Git。任何人都可以自由选择其中一个，但是显然比不使用任何版本控制要好。好书是Mike Mason的“ 使用Subversion的实用版本控制，第二版 ”或Travis Swicegood的“ 使用Git的实用版本控制 ”。

原作者：Bill Karwin

即使作为单个开发人员，源代码控制也提供了巨大的好处。它使您可以存储代码的历史记录，并随时还原到以前的软件版本。这使您可以毫无畏惧地灵活地进行试验，因为您始终可以还原到正在运行的源代码的另一个版本。

这就像有一个巨大的“撤消”按钮，一直回到您的第一行代码。

没有开始使用版本控制，几乎就不可能实现它。如果多个开发人员在同一个代码库上工作，这是必不可少的...但是对于单个开发人员来说，它也很有用。

它跟踪代码中的更改，并允许您回滚到以前的版本。它使您可以尝试以下知识：如果有任何问题，可以撤消更改。

您将获得安全性（就代码的备份而言）和代码的版本控制（假设您养成了经常提交更改的习惯）。即使没有其他人最终与您一起编写代码，两者也是非常好的事情。

版本控制非常适合检查以前的版本，即使您一个人工作也是如此。例如，如果您不小心删除了代码或文件，则可以找回它；或者您可以比较以前的版本，以查看为什么会出现新漏洞。如果您是一个在多个位置工作的人，这也很好。

我个人最喜欢的是git。

使用版本控制有很多原因，即使您是唯一会接触代码的人。

• 备份 -如果您的硬盘崩溃了怎么办？您在任何地方都有副本吗？
• 修订历史记录 -您当前是否将代码副本保存在其他文件夹中？版本控制使您能够跟踪一段时间内的更改，并使用工具轻松地区分不同的修订，合并，回滚更改等。
• 分支 -测试一些更改，仍然跟踪您在做什么，然后决定是否要保留它并将其合并到主项目中或将其丢弃的能力。

如果您将代码置于版本控制之下，则可以非常轻松地查看已更改（或忘记添加到基准）的文件。

似乎没有其他人明确提及的是发布的标签或标签。如果您的客户端使用版本1的软件，而您正在忙于版本2，那么当客户端报告错误并需要构建1.1版时，该怎么办？

源代码控制系统将使您可以标记出您制作的每个发行版，以便稍后再使用它，进行修订（并将该修订合并到新的版本2代码中）并进行新发行，而不必担心您可能会意外地交付某些内容。还没准备好

源代码控制是现代软件开发的核心部分。如果您不使用它（即使是个人项目，因为您拥有的经验越多越好），那么您就做错了。

通常，我在面试工作时会问的第一个问题是“您使用什么进行源代码控制？” 到目前为止，只有一个地方说“ Nothing”，但他们正计划修正“ Real Real now ...”

其他开发人员是否参与的事实与版本控制系统的需求完全正交。

您可以是唯一的开发人员，但仍将受益于：

• 您所有更改的历史记录
• 能够回顾那个历史
• 能够尝试源代码并仍具有可用版本（分支）的能力
• 备份副本（尤其是如果您使用其他计算机作为源控制服务器，并且如果定期备份该计算机，则更是如此）

现在，如果您有一个小组在同一个代码库版本控件上进行开发，则仍然有必要，因此

• 人们可以同时编辑同一文件（取决于特定的系统，但是大多数理智的文件都允许您执行此操作）
• 你可以告诉谁对代码做了什么

当涉及的人员更多时，取决于开发样式，选择哪个版本控制工具就更相关。

这也与备份旧文件有关，为什么它被称为“ Subversion”。因此，您可以管理工作的多个版本，在其中可以返回（还原）并管理它的不同实现（分支）。

您可能会发现您拥有该程序的有效版本。

您决定在一段时间内添加一些新功能，然后再发布。

您开始收到错误报告，这些错误报告会影响您认为没有接触过的某些代码。

例如，通过使用SVN，您可以移回旧版本，并检查是否存在新的错误。一旦找到引入该错误的版本，就可以更轻松地对其进行修复，因为您可以将有效的版本与无效的版本进行比较，并查看更改的内容，从而缩小搜索范围。

即使您是唯一的开发人员，源代码控制也有许多用途。

听起来您正在寻找重量更轻的东西。查阅Mercurial（很棒的参考书）。我用它来做所有事情，从源代码到个人信件。

一些好处：

• 巨型撤消按钮，因此您可以在代码实际运行时返回上周的那段宁静日
• 一次性代码。不确定这是否是做某事的最佳方法？进行分支并进行实验。如果您使用的是像水银一样的DVCS，那么除了您之外，任何人都不必知道。
• 同步开发。我在4台不同的计算机上进行开发。我在它们之间推拉以保持当前状态，因此无论我在哪一个版本上，都拥有最新版本。

即使您还没有需要较旧版本程序的情况，拥有源代码控制也可以让您更有信心进行重大更改。

使用源代码控制后，我发现自己进行了更加积极的重构，因为我一直都知道可以轻松恢复工作版本。

我也是最近才开始对版本控制感兴趣的。在版本控制系统中，您具有代码存储库的概念。很快就会学习到很多新的Shell命令，以便您可以与此存储库进行交互。

将代码保存到文件后，可以将其提交到项目的存储库。在开发代码并提交更改时，存储库会进行一系列修订。您可以通过检阅修订来访问其中任何一个。如果您是一个人工作，除非丢失了代码文件或想在其他计算机上工作，否则不太可能需要进行大量签出。在这些情况下，您通常会签出所有文件的最新版本。

就我自己而言，当我决定重构某些东西时，我不再保留名为“ project_old”的文件或文件夹。我所做的任何更改都将以增量方式存储，并且我将始终能够向后退回到整个项目。我现在很少使用FTP进行部署，因为我只是通过ssh签出代码。仅下载已更改的文件，如果需要在服务器上重新加载，则终端已经存在。

我发现有关GIT的演讲很有启发性。http://www.youtube.com/watch?v=4XpnKHJAok8

在Google的一次演讲中，Linus Torvalds提出了使用一个版本控制系统而不是另一个版本控制系统的论点。为此，他解释了它们如何使用概念进行工作，然后比较了实现它们的不同方法。

即使您自己一个人工作，您也可能想要颠覆之类的东西，以便拥有所有更改的历史记录。您可能想一次查看一段代码，以记住为什么进行更改。

经常签入时，具有源代码管理也很有用。如果您经常签入，那么您也始终处于经常回滚的状态。很多时候，您可能会开始走一条解决问题的道路，然后意识到这是走错了路。很多时候，您可能会一直走在错误的道路上，最终建立一个糟糕的解决方案-仅因为您不想失去所有工作。通过经常检查，“幸福”的最后一点并不遥远，因此，即使您走错了路，也可以始终回滚并重试，并提出更优雅，更简单的解决方案。这始终是一件好事，这样您就可以了解和维护您将来编写的内容。

这取决于项目的规模以及您对项目的某些部分改变主意的频率。对于仅以线性方式完成某事的小型项目，版本控制可能不会有太大帮助（尽管如果您意外删除或破坏了没有版本控制的文件，您会哭泣）。

但是几周前，我遇到了一个朋友，他自己一个人编写了一个庞大的业余爱好项目。他有十到二十个代码副本，后缀为“ X1”，“ X2”，“ test”，“ faster”等等。

如果你做了你的代码的两个以上的副本，你需要版本控制。一个好的版本控制系统使您可以撤消前一段时间所做的更改，而不必撤消所做更改后所做的工作。它使您可以查看何时进行了某些更改。它使您可以将代码分成两个“路径”（例如，一个用于测试新想法的路径，另一个用于保持“尝试并信任”的代码安全，直到完成测试为止），然后将它们合并在一起。

现在是2019年。在这个相对较晚的日期，我遇到反对使用Git的异议。异议我在这里看到一些反对意见。该讨论极大地阐明了使用源代码控制而不是简单地创建命名备份副本的必要性。一个关键点是即使在我们只有一个开发人员项目的情况下，也可以使用源代码控制。没有人是完美的。你犯错了。如果您非常优秀和聪明，那么您将要开发更复杂的应用程序；但是您仍然会犯一些错误，这可以解决。真是的，皮特！我从不使用Linux，但我认为我们都尊重Linus Torvalds的出色技术。他认识到源代码控制的重要性，并且为Git的诞生做出了重要贡献。出于此处给出的所有原因，这是一个总结。Torvalds明白了：源代码管理非常重要：使用源代码管理。感谢所有对这个长期运行的话题发表评论的人。