版本控制是一个小的开发组（1-2名程序员）所必需的吗？
我试图辩论版本控制对于一个或两个开发人员是重要的。
更具体地说，我在一个通常有两个PHP开发人员的部门工作，使用共享框架。 他认为，在我们的开发系统中安装Subversion没有任何价值，而我认为偶尔能够回滚查看以前的代码是很好的，特别是当发生难以解释的错误时，指向一些类。
我认为Subversion提供了最简单的方法来创build和跟踪更改，出于各种原因，包括debugging。 Subversion会保存任何时间吗？
我只是要在这里堆，说是的。 就像26岁的17岁那样
没有某种源控制是纯粹的疯狂。
这是事实。 我做了有和没有源代码控制的小项目（不是我的select）。 没有，它只是糟透了。 没有规范的版本的项目，你永远不知道谁有什么和合并变化是一个痛苦的练习。
实际上，任何超过5行的代码都应该在某种版本的控制之下。
即使你自己正在从事一个项目，你也总是希望拥有某种源代码控制。
有一个变化的历史是至关重要的，能够看到一个代码的状态在任何给定的时间。 有一个回顾项目历史的各种理由，从刚才能够回滚一个坏的改变到为旧版本提供支持的时候，当客户只需要一个补丁修复一个bug而不是升级到一个更新版本该软件。
没有某种源控制是纯粹的疯狂。
肯定是的。
即使你是一个程序员，你也需要版本控制。 您可以简单地将代码与任何快照进行比较，是无价的。
我的build议 – 去吧！
[一旦我没有版本控制的生活。 现在我不能了。]
我是一个程序员，我觉得它是非常宝贵的，因为我有时想把事情推回去，或者比较一下早期的版本。
此外，我版本的文件从用户和类似的东西。
这是跟踪你的发展的好方法。
颠覆 – 绝对不是。 这是集中和合并的支持不太好。
版本控制 – 绝对是！ 即使是独立开发者也需要它！
而且小而快的移动团队需要分布式的版本控制，所以select下面的一个：
- 混帐
- 善变
- 的darcs
是的，有一个学习曲线。 去分布式，你可以学习它。 是的，你可以感谢我。
那些分布式存储库在哪里生活？ 这里有一些想法：
- 在你的个人USB记忆棒中（不要把自己限制在一个 USB记忆棒上，把它们分发到多个地方，比如你的银行里的保险箱）
- 另一个在安全的地方（异地，不同的地点，networking另一端）火灾，地震或龙卷风不能同时伤害你的来源）作为备份
- 一个在中央服务器，你的或类似的github
- 在开发者机器中多个副本
- 临时登台服务器附近的临时储存库
- 生产库存在生产地点附近
版本控制将保存你的屁股。 一个不使用版本控制的专业开发人员是软件不当行为中不可侵犯的less数几个事情之一。
即使你是一个单独的开发者，它也会
- 让你回到function的工作
- 自动维护备份：检入并备份。
- 当你自己打结时，让你撤销你的本地变化。
- 让您回到正在运行的版本，在testing环境或特定客户的环境中进行debugging。
- 如果使用得当，它也可以让你看到所有与修复有关的特定问题的变化，这是一个非常宝贵的debugging工具。
如果你不止一个开发者，那么不pipe你多么小心，它都会让一个程序员不会覆盖所做的更改。
这些只是帮助您赢得关于是否使用版本控制的任何争论的基础知识。
我是一个“单人乐队”的程序员，当我发现自己复制整个应用程序并把它们放在一个名为“backup”的文件夹中，然后命名为“20080122-backup”时，我终于开始使用版本控制。 我想很多人开始这样。 所以问题不在于你是否应该使用版本控制，而应该用正确的方式来做，还是应该把一些半分的自制的传真打包到一起？
版本控制只在程序员数量> 0的情况下才需要。
使用任何系统的工作，你很舒服，但如果你做开发，那么你需要版本控制（理想情况下，设置源，至less有两台机器甚至在担心备份之前）。
除此之外 – 寻找一个系统，让你提前做出承诺和经常。
我可能听起来很奇怪，但是我认为每个项目，即使是第一个项目，都应该考虑持续集成，即从零开始构build和testing这个系统，每次改变都至less提交一次，或者至less定期进行。 为什么？ 这a）让你相信你在VCS中有一个可构build的系统，b）确保你有一个干净的构build来testing和部署。
我特别不知道Subversion，但是我相信每个项目，即使是单个开发者，都应该使用版本控制。 我会看看几个选项（CVS，SubVersion，git，Bazaar，Visual SourceSafe），看看哪一个最适合你的团队的愿望。
版本控制是程序员最重要的工具，甚至比实际的编程语言更重要。 无论你有多less用户，始终需要源代码pipe理。 我不知道有多less次我做了一个突破性的改变，然后需要回头去处理旧的代码，或者至less看看原代码是如何运作的。 我在小团队工作，我们使用SVN通知程序让我们知道什么时候提交。 这使我们可以检查彼此的工作，而且你没有得到可怕的“你有没有检查你的代码？” 一直提问。 从头开始使用源代码控制将消除许多令人头痛的问题（覆盖，丢失的代码，争夺谁改变了什么），你可能会面临。
绝对。 当你冒险的编码path变成狼群密集的时候，真的没有别的办法来处理回滚到已知的良好状态。
你可以支持它。
我有一个只有我工作的项目，版本控制使我的生活变得如此简单。 比如说我决定实现一个新的function。 不pipe出于什么原因，我决定把它弄糟 – 也许我把它写错了，也许我改变了自己的想法。 我只需要从SVN恢复到以前的版本，而不是手动还原每个涉及的文件。
颠覆不是。 但是源码控制是。
无论您是单个开发人员还是一组开发人员，在开始编码ANYTHING之前，您都必须执行以下操作：
- build立一个版本控制系统 。 使用你喜欢的任何系统，git，SVN，Mercurial。 没关系，只要你知道如何使用它。
- build立一个协作文档系统 。 使用维基或trac，或任何其他这样的系统，你知道如何使用。
- build立构build系统 。 使用Make，ANT，Maven或者其他你知道如何构build的构build系统。
- 编写第一个testing用例 。
在完成这四个操作之前，不要编写主应用程序的一行代码
任何没有进行版本控制的人都只是做错了。
版本控制可以具有以下优点：
- 你提到的回滚总是方便的
- 用一些你可以固定以前的版本，并运行它，而不回滚
- 有助于防止两个人同时在页面上工作，这可能会导致几个问题
但是，如果你不select一个好的话，那么它也会有其不利影响
无论团队规模如何，我都强烈推荐源代码控制。 我有太多的深夜会议，我打破了我的代码，没有源代码控制去旧的工作版本。
是！
对不起，大喊:-)
版本控制不仅适用于回滚版本。 它会为安装旧版本的文件或意外地覆盖旧版本的新版本提供很大的安全性。
有一件事我只是现在习惯了，真正有用的是能够分支和合并不同的版本。 如果您有最后期限，但是您正在开发尚未准备好的新function，则可以在开始添加该function之前进行分支。 创build一个没有该function的可交付版本，并在截止date过后没有问题地合并这两个版本。
当然，即使对于一个人来说，版本控制也是必要的。
select保存上下文而不仅仅是代码中的变化是源代码控制所做的伟大的事情，你从“把这个文件和这个文件改成了行文 ”转到“ 我添加了一个新的选项来做… ”这是真的有价值。
不要听我说，虽然有一篇文章是关于这件事的
捕捉上下文
是的，但只适用于规模大于0的开发者团队
当我closures我的IDE /文本编辑器/任何和第二天回来意识到我想撤消可能会最后一个头脑的错误，源代码控制是在那里让我回落，或使用分支和执行一些野生实验码。 没有资源控制，我不能这么自由地做这些事情。
对于规模大于1的团队，你有一个中央备份，你有团队范围撤消，分布式工作更容易（可能），当团队规模超过1时，无论如何，无论你的团队配合多远。
我会争取Git ，主要有两个原因
- 微不足道的build立回购。 cd进入目录， git init ，你就完成了
- logging！ 使用任何types的vcs都可以让您轻松/明显/简单地logging您为什么要进行更改。 尤其是使用dvcs，可以快速，轻松地查看何时，以什么方式进行更改。 由于dvcs在本地拥有较长的信息， 因此与远程机器上的svn不同， 它看起来很快，很容易 。
这对于Mercurial来说也是显而易见的。 他们肯定这样的颠覆不是那么容易的。]
所有对1-2名开发人员来说都是源代码pipe理的人来说，是完全正确的。 相信我们 ：-）
回到大学，我有一位教授让我们使用源代码控制。 我们都踢了，尖叫，因为CVS似乎太复杂，听起来像学生项目的矫枉过正。 最终我们都来了，甚至从那以后的简单的项目，我把他们都在源代码pipe理。 我一直坚持到现在，并且让自己摆脱了许多小时的挫折。
简单的答案是的。
不要重申，但不能说足够。 你应该有源代码pipe理。 一旦设置好，Subversion是非常容易的，几乎为零。 它不应该超过5-20分钟设置。 你也有其他的select，比如GIT。 所以就选一个，然后把你的源码放在那里 – 答案结束。 🙂
版本控制是的，你总是需要执行版本控制。
SVN？ 不，我使用Git。
当我想去商店时，我把我的车运送到购物中心。 没有必要把气放在我的车里。 我可以select推车，但为什么呢？
同样select不使用版本控制….
当你build立系统并设置其他开发者时（特别是如果他们不熟悉versioncontrol（或特定的subversion）），会有一些时间的损失。
但是能够回滚到以前的（工作）版本的好处以及对签入文件进行简单差异的可能性将是非常值得的。
最大的问题是奖励式的大多数事情是在“辛勤工作”之后。 🙂
注意，一个不同的，但更轻量级的解决scheme可能是在Windows上增加“Shadow Copy”，如果这是你的服务器操作系统（尽pipe我猜测它不会）。 这样做的好处是，你不会打扰你的合作开发者学习颠覆，但你将能够在需要时恢复到旧版本…
在开始一个项目时，版本控制应该是你首先想到的。 其次是自动构build，第三是testing，第四是将您的testing与您的构build。
VSS很好，但mucho dinero。
尝试mercurial（hg）而不是svn
是的，如果你是一个专业的开发人员，那么你绝对需要使用版本控制！
