我正试图争论这样一个观点，即版本控制对于一两个开发人员来说都很重要。

更具体地说，我在一个部门中工作，通常有两个PHP开发人员使用一个共享框架。他认为在我们的开发系统上安装Subversion并没有增加价值，而我认为偶尔回滚以查看以前的代码是一件好事，尤其是当发生无法解释的错误而无法固定时-指出某些课程。

我认为Subversion提供了最简单的方法来创建和跟踪更改，原因有多种，包括调试。 Subversion会节省时间吗？

解决方案

回答

肯定是的。

即使我们是一个程序员，也需要版本控制。我们可以将代码与任何快照及时进行比较的简单性是无价的。

我的建议去了！

[一旦我没有版本控制就生活了。现在我不能了。]

回答

我并不特别了解Subversion，但我相信每个项目，甚至只有一个开发人员的项目，都应该使用版本控制。我将研究几个选项(CVS，SubVersion，git，Bazaar，Visual SourceSafe)，然后看看哪个选项可以最好地满足我们团队的需求。

回答

我是一个程序员，我发现它无价之宝，因为有时我想回滚，或者将其与早期版本进行比较。

此外，我还会根据用户和类似情况来发布文档版本。

这是跟踪发展的好方法。

回答

绝对地。当我们冒险尝试的编码路径上到处都是狼群时，实际上没有其他方法可以将回滚处理到已知的良好状态。

我们可以备份它。

回答

我只有一个项目，而版本控制使我的生活变得更加轻松。例如，假设我决定实施一项新功能。不管出于什么原因，我还是决定将其丢弃，也许是我写错了，也许我改变了主意，以实现它。我所要做的就是从SVN恢复到以前的版本，而不是手动恢复涉及的每个文件。

回答

版本控制可以具有以下优点：

• 正如我们提到的，回滚总是很方便
• 对于某些版本，我们可以固定以前的版本并在不回滚的情况下运行它
• 帮助防止两个人同时在一个页面上工作，这可能会导致多个问题

但是话又说回来，如果我们不选择一个好的产品，它也有其缺点。

回答

即使我们自己一个项目，我们始终总是希望拥有某种源代码控制。

拥有更改历史对于在任何给定时间都能查看代码库的状态至关重要。回顾项目历史的原因有很多种，从能够回退错误的更改到当客户只需要补丁来修复错误而不是升级到较新版本的客户时，就可以为旧版本提供支持。该软件。

没有某种源代码控制是纯粹的精神错乱。

回答

当我们设置系统并指导其他开发人员时，尤其是在他们不熟悉版本控制(或者特定于Subversion)的情况下，会浪费一些时间。

但是，能够回滚到先前(工作)版本的好处以及轻松进行检入文件差异的可能性将是非常值得的。

最大的问题是，像大多数事情一样，回报是在"辛勤工作"之后产生的。 :)

请注意，如果这是服务器操作系统，则可能会使用另一种但更轻巧的解决方案在Windows上启用"影子复制"(尽管我猜不会)。这样做的好处是我们不会因为学习颠覆而困扰共同开发者，但是我们将能够在需要时恢复到较旧的版本...

回答

是的！

抱歉大喊大叫:-)

版本控制不仅对回滚版本有用。这将为防止推出较旧版本的文件或者意外地用较旧版本覆盖新版本等提供很大的安全性。

我现在才习惯的一件事是，真正有用的是分支和合并不同版本的能力。如果有最后期限，但我们正在开发的新功能尚未准备就绪，则可以在开始添加该功能之前分支。创建不具有该功能的可交付版本，并在截止日期没有问题的情况下合并这两个版本。

回答

当然，即使对于一个人的项目，版本控制也是必需的。

保存上下文而不只是更改代码的选项是源代码管理所做的伟大工作，我们从"将其归档并在行中进行了更改"变为"我添加了一个新的选项来做……"，这的确是有价值的。

兰德斯写了一篇很棒的文章，不要听我说

捕获上下文

回答

即使团队规模很小，Subversion之类的版本控制也很重要，不仅要能够在各个修订版之间进行比较，而且还要回滚到以前可以使用的版本。

但是，所有这些都增加了复杂性。不仅要保存代码，还必须将其检入系统。每个主要的版本控制系统都有可轻松检入代码的工具，许多工具都将直接与IDE集成。但是，这并没有改变以下事实：保存代码文件时还必须执行其他步骤。将代码放置在版本控制系统中会产生开销，但是有工作代码可以在发生问题时回滚，可以弥补这一额外开销。

回答

仅当程序员人数> 0时才需要版本控制。

无论使用哪种系统，只要我们满意，就可以使用它，但是如果我们要进行开发，则需要版本控制(理想的设置方式是，即使在担心备份之前，源至少应位于两台计算机上)。

除此之外，我们还需要一个可以让我们提早提交并经常提交的系统。

我似乎有点奇怪，尽管这听起来似乎是在朝着这样一个观点：每个项目，即使是一个开发人员，也应该考虑持续集成，即，每次提交更改或者至少定期进行更改时，都要从头开始构建和测试该系统。基础。为什么？这a)使我们确信自己在VCS中具有可构建的系统，并且b)确保实际上具有可测试和部署的全新版本。

回答

颠覆-绝对不是。它是集中式的，合并支持不是很好。

版本控制-绝对是！即使是单独的开发人员也需要它！

而规模较小且变动迅速的移动团队需要分布式版本控制，因此请选择以下选项之一：

• 吉特
• 水银的
• 达奇

是的，有一个学习曲线。去分发，我们可以学习它。是的，我们稍后可以感谢我。

这些分布式存储库位于何处？这里有一些想法：

• 在个人USB记忆棒中(不要将自己限制在一个USB记忆棒中，也可以将它们分配到多个位置，例如银行中的保险箱)
• 另一处在安全的地方(异地，不同位置，网的另一侧)，在该处火灾，地震或者龙卷风无法同时损害来源(作为备份)
• 一个在中央服务器中，我们自己或者类似github的服务器
• 开发人员机器中的多个副本
• 登台服务器附近某处的登台存储库
• 生产仓库靠近生产现场的地方

回答

版本控制是程序员拥有的最重要的工具，甚至比实际的编程语言还要重要。无论我们有多少用户，都应该始终需要源代码控制。我不知道我做了几次重大更改，然后需要回过头来处理旧代码，或者至少只是看看原始代码是如何工作的。我在小型团队中工作，我们使用SVN通知程序来通知我们什么时候提交。这样一来，我们就可以互相检查彼此的工作，而我们却不会感到恐惧："我们是否已签入代码？"一直在提问。从一开始就使用源代码管理将消除我们可能会遇到的许多麻烦(覆盖，代码丢失，为谁更改内容而战)。

回答

在开始项目时，版本控制应该是我们考虑的第一件事。第二是自动构建，第三是测试，第四是将测试与构建结合在一起。

回答

我是一名"单身乐队"程序员，当我发现自己要复制整个应用程序并将它们放入一个名为" backup"的文件夹中，然后再为它们命名为" 20080122-backup"时，我终于开始使用版本控制。我想很多人都是从这种方式开始的。因此，问题不是我们是否应该使用版本控制，而是应该以正确的方式进行操作，还是应该一起拼凑一些半熟的自制传真？

回答

颠覆不是。但是源代码控制是。

回答

源代码控制只花费设置时间就不会花费我们任何费用。这很容易。

回答

是的，即使我们是唯一的人，源代码管理也是必须的。当然，我们不会使用它来控制谁在处理哪些文件，但是如果我们在代码中犯了一个大错误，则能够扮演角色确实是一件容易的事。

回答

我只是在这里堆成一堆，然后说"是"。就像@ 17之26

Not having some sort of source control is pure insanity.

这是真话。我已经完成了带有或者不带有源代码控制的小型项目(不是我的选择)。没有它，那太烂了。该项目没有规范的版本，我们永远都不知道谁拥有什么，而合并更改是一项痛苦的练习。

实际上，大约5行代码中的任何内容都应该处于某种形式的版本控制之下。

回答

我想成为第一个回答"否"的人。学习如何有效使用它需要时间。这可能会使新用户感到困惑。滚回来？合并更改？能够分支项目？还是确保我们现在要删除的所有这些东西不会永远丢失？它仅在少数情况下有用，并且我不确定100％地确定找到SVN或者TortoiseSVN并下载它所花费的10分钟时间，再加上30分钟的使用时间知识是值得的。

太太：是的。你的。伙伴。 *)＆％$＃。疯狂的？

我们有几种可能在工作中使用的工具。没有对CVS或者SVN的广泛支持，而是大多数情况下的商业亲戚。
我在个人计算机上使用了tortoiseSVN来处理自己的WORD文档和电子表格，我发现当其他人编辑我的电子表格并将其发送回我时，MERGE功能确实会有所帮助。 (我倾向于通过将不同版本保存为xml电子表格来进行合并。)
或者在多台PC上使用文档或者电子表格时备份更改。

但是，对此争论不休。告诉她/他如何安装它，并演示对同一文档的一些编辑。或者让他们自己训练软件木工。

回答

是否可以选择Visual SourceSafe？我是一个程序员，最近一次一直使用它作为存储库，没有任何问题，但我不断听到恐怖故事。真的那么糟糕吗？

回答

无论我们是一个开发人员还是一组开发人员，在开始编写任何代码之前，都必须执行以下操作：

• 设置版本控制系统。使用任何我们喜欢的系统，git，SVN，Mercurial。只要我们知道如何使用它，都没有关系。
• 建立一个协作文档系统。使用Wiki或者trac，或者我们知道如何使用的任何其他此类系统。
• 设置构建系统。使用Make，ANT，Maven或者我们知道如何构建的任何其他构建系统。
• 编写第一个测试用例。

在完成这四个步骤之前，请不要对主应用程序的任何一行进行编码

回答

VSS很好，但是可以使用dinero。

回答

尝试用汞(hg)代替svn

回答

任何不执行版本控制的人都是错误的。

回答

是的，如果我们是专业的开发人员，那么我们绝对需要使用版本控制！

回答

我只是把它扔在那里，但我相信PERFORCE是免费的
最多2位开发人员。不知道设置起来有多容易。

我猜我们会想要一些易于设置和使用的东西。

回答

原始的" rcs"工具仍然存在，并且仍然可以运行(在unix和Windows / dos上)，并且可能是这些工具中最简单的一个，这就是为什么我向在同一系统上工作的两人团队推荐它的原因(例如同一办公室，同一文件服务器或者Unix主机)。只有在单独的环境中工作时，才值得进入像Subversion这样的客户端/服务器模型。

回答

如果满足以下至少一项，则需要源代码控制：

1)有不止一个开发人员

2)该项目超过一小时

3)项目中有超过5000行代码

因此，如果我们是两个人，则需要使用版本控制。另外，如果我们独自一人，但是项目达到了不小的复杂性……则需要版本控制！

回答

我会为git辩护，主要有两个原因

• 设置回购协议很简单。 cd进入目录git init，就可以完成了
• 记录！使用任何种类的vcs都可以很容易/很明显/很容易地记录为什么要进行更改。特别是拥有dvc，可以非常快速，轻松地查看何时，什么以及为什么进行更改。由于dvc在本地具有很长的信息，因此与在远程计算机上的svn不同，它可以快速，轻松地进行查找。

[这些显然对于Mercurial也是正确的。他们确信这种​​颠覆并不是那么容易。]

回答

版本控制将保存屁股。不使用版本控制的专业开发人员无疑是少数软件不当行为类别之一。

即使我们是一个孤独的开发人员，它也会

• 让我们返回功能正常运行的时间
• 自动维护备份：检入并备份。
• 当我们陷入困境时，让我们撤消本地更改。
• 让我们返回生产环境中，测试环境中或者特定客户环境中运行的版本以进行调试。
• 如果使用得当，它还将使我们看到与针对特定问题的修复程序相关的所有更改，这可能是宝贵的调试工具。

如果我们是一名以上的开发人员，那么无论我们有多小心，它都将使一名程序员无法覆盖另一名程序员所做的更改。

这些只是可以赢得有关是否使用版本控制的任何论点的基础知识。

回答

每个人都说必须对1-2个开发人员进行源代码控制是完全正确的。相信我们 ：-)

回到大学时，我有一位教授让我们使用源代码控制。我们所有人都大喊大叫，因为CVS似乎太复杂了，听起来对学生项目来说太过分了。最终我们都来了，甚至从那时起对于简单的项目，我都会将它们全部放在源代码控制中。我一直坚持到今天，并摆脱了许多小时的挫败感。

回答

源代码控制将使我们高枕无忧。我是mISV，本周初丢失了系统硬盘。我的代码在几个Subversion存储库中。我刚刚完成了代码的重新组织，所以我可以签出然后继续。

我正在等待新的硬盘驱动器到货。我很安心，当新的硬盘驱动器到货时，我将能够继续改进我停产的产品。

回答

是的，但仅适用于规模大于0的开发人员团队

当我关闭我的IDE /文本编辑器/任何设备，然后第二天回来意识到我要撤消的操作可能会遇到严重的错误时，可以使用Source control来回退，或者用来分支并在我的设备上进行一些疯狂的实验代码。没有源代码控制，我不能这么自由地做这些事情。

对于规模大于1的团队，我们有一个中央备份，我们可以进行整个团队的撤消，这很容易(可能)进行分布式工作，当团队规模超过1时，无论队友有多远，这实际上都是我们正在做的。

回答

是的，必须进行源代码控制。

我使用Sourcegear Vault，这对于单个开发人员是免费的。

回答

无论团队规模如何，我都强烈建议我们使用源代码控制。我在深夜的会议上太多了，在那我破坏了我的代码，并且没有源代码控制可用于较早的工作版本。

回答

源代码控制是。
颠覆号

Subversion适用于需要很好地处理分支的非常复杂的东西。否则，不值得学习和维护它。

还有许多其他更直接的小尺寸源代码控制(我个人建议PerForce)

顺便说一句，我会排名创建一个构建系统比版本控制更重要。

现在，只有很少的人，可以通过仔细分割工作文件来管理源代码管理，但这并不能为我们提供版本控制(它实际上是自动构建到我们将找到的任何源代码管理中的)
至少，我们需要能够从几周后回头查找文件的版本。

回答

简单答案是。

不重申，但还不能说足够。我们应该具有源代码管理。 Subversion设置起来非常简单，开销几乎为零。从字面上看，设置时间不会超过5-20分钟。我们还有其他选择，例如GIT。因此，只需选择一个，然后将来源放在答案的结尾即可。 :)

回答

对于小型团体而言，Subversion并不是过大的杀伤力，但不应被视为替代适当的项目管理。长话短说，如果人们没有时间表和适当的沟通，那么不使用版本控制就更好了，它可能导致比目标解决的问题更多的问题。实施版本控制时应回答的问题：

• 谁负责管理存储库？
• 我们有发布时间表吗？我们如何传达合并变更？
• 当前的源代码管理(文件，文件系统上的副本)与我们打算通过Subversion实现的目标之间有什么区别(提示，如果我们没有明确的答案，请不要使用它)。
• 我们对Subversion的使用将如何具体地纳入项目管理计划中？

回答

版本控制是，我们始终需要执行版本控制。

SVN？不，我，我用的是Git。

回答

当我想去商店时，我开车去购物。没必要在我的车里放汽油。我可以选择推车，但为什么呢？

同样，选择不使用版本控制。

回答

考虑这种常见的情况，例如，在几个月的时间里，将修补程序应用于某些不稳定的功能" A"。在这几次尝试中，开发人员编辑了多个文件，尽管功能" A"已修复，但另一个功能" B"已损坏。通常这是在一段时间后才实现的，只能回忆起功能" B"在某个时间点正在工作。在存在版本控制的情况下，所有开发人员所要做的就是遍历先前的修订并达到破坏了" B"的修订，然后撤消那些部分。使用简单的除法和规则即可得出错误版本(如果当前版本为2000，请检查1000(如果在该版本中有效)然后检查1500 ...)。

在没有版本控制的情况下，开发人员至少必须重新考虑如何使其再次工作，因此必须将新的时间花在花费了完整时间的事情上。现在，这可能是项目的全部功能之一，甚至单个开发人员也可能忘记了确切的规范。因此，需要进行规格查找，而不需要什么？

我有很多次感觉就像是在打头顶一些有经验的开发人员，他们没有在他们正在工作的项目中使用版本控制，后来我不得不在同一项目上应用一些修复程序。一位这样的开发人员过去常常懒于设置和维护SVN，而且当我问他SVN的工作状况(当我被分配工作时)时，他不会正确地告诉我，因为他会忙于其他一些项目。

懒惰是人类常见的弱点。任何人都可以感到懒惰。我敢打赌，大多数人在重新考虑在另一种情况下已经完成的事情(缺少版本控制)时会感到懒惰或者更恼怒。那么，哪个更好？之前懒惰或者之后变得聪明懒惰。