我试图讨论版本控制对于一个或两个开发人员很重要的观点。
更具体地说，我在一个部门工作，通常有两个PHP开发人员使用共享框架。他认为我们的开发系统上安装了Subversion没有增加任何附加值，而我认为偶尔能够回滚查看以前的代码是很好的，特别是在发生难以解决的无法解释的错误时 - 指出一些课程。
我认为Subversion提供了创建和跟踪更改的最简单方法，原因有多种，包括调试。 Subversion可以随时保存吗？
答案 0 :(得分：244)
总是，始终希望拥有某种源代码管理，即使您自己正在处理项目。
拥有更改历史记录对于能够在任何给定时间查看代码库的状态至关重要。回顾项目历史的原因有多种，从仅仅能够回滚一个糟糕的变化到提供对旧版本的支持，当客户只想修补补丁而不是升级到更新的版本时软件。
没有某种源控制是纯疯狂。
答案 1 :(得分：132)
我要打算在这里说谎。就像@17 of 26所说的那样
没有某种源控制是纯疯狂。
这是事实。我做过有和没有源代码控制的小项目（不是我的选择）。没有，它只是糟透了。没有规范版本的项目，你永远不知道谁拥有什么，合并的变化是痛苦的练习。
实际上，超过5行代码的任何内容都应该受某种版本控制。
答案 2 :(得分：94)
肯定是的。
即使您是单个程序员，也需要版本控制。您可以将代码与任何快照及时进行比较的简单性是无价的。
我的建议 - 去吧！
[有一次我没有版本控制。现在我不能了。]
答案 3 :(得分：62)
我是一名程序员，我发现它非常宝贵，因为我有时想要回滚一些东西，或者将某些东西与早期版本进行比较。
另外，我从用户和类似的东西中编辑文档。
这是跟踪开发的好方法。
答案 4 :(得分：27)
版本控制将保存您的屁股。不使用版本控制的专业开发人员是少数无可争议的软件不正当行为之一。
即使你是一个单独的开发者，它也会
如果您不止一个开发人员，那么无论您多么小心，都会让一个程序员覆盖这些更改，而另一个程序员将发生。
这些只是帮助您赢得有关是否使用版本控制的争论的基础知识。
答案 5 :(得分：26)
我是一个“单人乐队”程序员，当我发现自己复制整个应用程序并将它们放入一个名为“backup”的文件夹中，然后将它们命名为“20080122-backup”之后，我终于开始使用版本控制了。我想很多人都是这样开始的。所以问题不在于你是否应该使用版本控制，而应该以正确的方式进行，还是应该将一些半自制的传真机组合在一起？
答案 6 :(得分：26)
颠覆 - 绝对不是。它集中化，合并支持不太好。
版本控制 - 绝对是！即使是单独的开发人员也需要它！
小而快速移动的移动团队需要分布式版本控制，因此请选择以下其中一项：
是的，有一个学习曲线。分发，你可以学习它。是的，你以后可以感谢我。
那些分布式存储库存在于何处？以下是一些想法：
答案 7 :(得分：22)
版本控制仅在程序员数量> 1的情况下才需要。 0
使用任何系统都可以使用，但是如果你进行开发，那么你需要进行版本控制（理想情况下，即使在你担心备份之前，源也至少在两台机器上设置）。
除此之外 - 寻找一个允许您提前提交并经常提交的系统。
我几乎 - 虽然听起来很奇怪 - 朝着这样的观点前进：每个项目，甚至是1个开发项目 - 都应该关注持续集成，即从头开始构建和测试这个系统，每次都要进行更改或者至少定期。为什么？这个a）让你相信你在VCS中有一个可构建的系统，b）确保你有一个干净的构建来测试和部署。
答案 8 :(得分：10)
我特别不了解Subversion，但我相信每个项目，即使是一个开发人员，也应该使用版本控制。我会看几个选项（CVS，SubVersion，git，Bazaar，Visual SourceSafe），看看哪个（s）能满足你团队的最佳愿望。
答案 9 :(得分：10)
版本控制是程序员最重要的工具，甚至比实际编程语言更重要。无论您拥有多少用户，都应始终需要源代码管理。我不知道有多少次我做了一个突破性的改变，然后需要回去处理旧代码，或者至少看看原代码是如何运作的。我在小团队中工作，我们使用SVN Notifier告诉我们什么时候提交。这使我们可以审查彼此的工作，并且你没有得到可怕的“你有没有检查过你的代码？”一直有问题。从一开始就使用源代码控制将消除您可能面临的许多令人头疼的问题（覆盖，丢失代码，对谁改变了什么）。
答案 10 :(得分：6)
无论您是单个开发人员还是一组开发人员，在开始编码之前必须执行以下操作 ANYTHING ：
在完成这四项
之前，不要编写主应用程序的单行代码答案 11 :(得分：6)
任何不进行版本控制的人都只是做错了。
答案 12 :(得分：6)
Subversion不是。但是源代码控制是。
答案 13 :(得分：6)
绝对。当你冒险的编码路径变得与狼群密集时，真的没有办法处理已知良好状态的回滚。
你可以支持它。
答案 14 :(得分：6)
我有一个只有我工作的项目，而版本控制让我的生活变得如此简单。例如，假设我决定实施一项新功能。无论出于何种原因，我决定将其丢弃 - 也许我写错了，也许我改变了实施它的想法，无论如何。我所需要的只是从SVN恢复到以前的版本，而不是手动恢复所涉及的每个文件。
答案 15 :(得分：5)
无论团队规模如何，我都强烈推荐源代码控制。我有太多的深夜会话，我打破了我的代码，并且没有源代码控制来转到较旧的工作版本。
答案 16 :(得分：5)
版本控制具有以下优点：
但是，如果你不选择一个好的
，那么它也有它的垮台答案 17 :(得分：4)
当然，即使是单人项目，版本控制也是必要的。
保存上下文的选项而不仅仅是代码中的更改是源代码管理所做的伟大的事情，你可以从“ file this and change changed in line blah ”转到“ I添加了一个新选项... “这真的很有价值。
不要听我的话，虽然有一篇很棒的文章 rands 写了关于这个的文章
答案 18 :(得分：4)
YES！
抱歉大喊： - ）
版本控制不仅可用于回滚版本。它可以提供很大的安全性，防止推出旧版本的文件或意外覆盖旧版本等的新版本。
我现在已经习惯了一件非常有用的事情就是分支和合并不同版本的能力。如果你有一个截止日期，但你正在开发一个尚未准备好黄金时间的新功能，你可以在开始添加该功能之前进行分支。创建一个没有该功能的可交付版本，并在截止日期过后合并这两个版本没有问题。
答案 19 :(得分：4)
当我想去商店时，我会开车去购物回家。将气体放入我的车里是非常强烈的 。我可以选择推车，但为什么我呢？
同样选择不使用版本控制....
答案 20 :(得分：4)
版本控制是，您始终需要执行版本控制。
SVN？不，我，我用Git。
答案 21 :(得分：4)
是，但仅适用于尺寸为＆gt;的开发者团队。 0
当我关闭我的IDE /文本编辑器/无论如何然后第二天回来意识到我想要撤消可能会遇到愚蠢的错误，源代码控制是让我重新开始，或者用来分支并执行一些狂野试验我的代码。没有源代码控制，我不能这么自由地做这些事情。
对于规模不大的团队＆gt; 1你有一个中央备份，你可以在团队范围内撤消，分布式工作更容易（可能），当团队规模超过1时，无论你的队友有多远，你实际上都在做什么。
答案 22 :(得分：3)
简单回答是。
不要重申，但不能说够了。你应该有源代码控制。 Subversion非常简单，一旦设置就几乎为零开销。它实际上不应该花费超过5-20分钟来设置。你也有其他选择，比如GIT。所以只需选择一个，然后将你的资源放在那里 - 答案结束。 ：）
答案 23 :(得分：3)
每个人都说1-2个开发人员的源代码控制是必须的，这是完全正确的。相信我们： - ）
回到大学时我有一位教授让我们使用源代码控制。我们都踢了一惊，因为CVS似乎过于复杂，听起来像学生项目的过度杀戮。最终我们都来了，即使对于那时的简单项目，我也把它们全部放在源代码控制中。到目前为止，我一直在继续这样做，并且让自己免于经历了数小时的挫折。
答案 24 :(得分：3)
我认为 git ，主要有两个原因
[这些对于Mercurial来说显然也是如此。他们肯定对于颠覆来说并不容易。]
答案 25 :(得分：2)
版本控制应该是您在启动项目时首先考虑的事情。第二是自动构建，第三是测试，第四是将您的测试与构建相结合。
答案 26 :(得分：2)
我总是对我的私人项目使用某种版本控制（#programmers == 1），开头只是用数字复制，后来是RCS，然后是CVS，然后是subversion。看到你在哪个时间点改变了什么以及为什么无价值的好处。因此，如果版本控制对于单个程序员来说是好的，那么对于一个团队来说情况就不会更糟。
答案 27 :(得分：2)
如果至少满足下列条件之一，则需要源代码管理：
1）有多个开发者
2）该项目超过一个长度
3）该项目有超过5000行代码
所以，如果你是两个人，你需要使用版本控制。此外，如果你是独自一人，但你的项目达到了一个微不足道的复杂性......你需要版本控制！
答案 28 :(得分：2)
是的，如果您是专业开发人员，那么您绝对需要使用版本控制！
答案 29 :(得分：2)
尝试mercurial（hg）而不是svn
答案 30 :(得分：2)
VSS很好，但很多dinero。
答案 31 :(得分：2)
当您设置系统并安装其他开发人员时会有一些时间损失 - 特别是如果他们不熟悉版本控制（或特定的颠覆）。
但是能够回滚到以前（工作）版本的好处以及对签入文件进行简单区分的可能性将是非常值得的。
最大的问题是奖励 - 就像大多数事情一样 - 来自'努力工作'。 ：）
注意，一个不同但更轻量级的解决方案可能会在Windows上启用“Shadow Copy”，如果那是你的服务器操作系统（虽然我猜它不会）。这样做的好处是你不会因为学习颠覆而烦扰你的合作开发者，但是你需要在需要时恢复到旧版本......
答案 32 :(得分：1)
我只是把它扔到那里，但我相信PERFORCE是免费的 最多2名开发人员。不知道设置有多容易。
我猜你想要一些易于设置和使用的东西。
答案 33 :(得分：1)
源代码控制将让您高枕无忧。我是一个mISV，本周早些时候丢失了我的系统硬盘。我的代码在几个Subversion存储库中。我刚刚完成了代码的重新组织，所以我可以退房并去。
我正在等待新的硬盘到货。我可以放心，当新硬盘到达这里时，我将能够继续增强我的产品。
答案 34 :(得分：1)
最初的'rcs'工具仍然在那里仍然可以工作（在unix和windows / dos上）并且可能是这些工具中最简单的工具，这就是为什么我推荐它为一个两人工作的团队相同的系统（例如同一个办公室，同一个文件服务器或unix主机）。如果你在不同的环境中工作，那么进入像颠覆这样的客户端/服务器模型是值得的。
答案 35 :(得分：1)
是的，源控制是必须的。
我使用Sourcegear Vault，对于单个开发者来说是免费的。
答案 36 :(得分：0)
我已经在几个工作中编写了15年的编码，并且在我们开始使用源控制解决方案之前从未丢失过代码或版本控制问题，我们一次性丢失了数周的工作。使用版本控制的开销很浪费。
我不认为这是必要的，但是，我主要做的是Web应用程序，而不是完整的程序。我从来没有和其他程序员同时在同一个网页上工作过。
答案 37 :(得分：0)
即使是一个小团队，像Subversion这样的版本控制也很重要，不仅可以在修订版之间进行比较，还可以回滚到之前正在运行的版本。
但所有这些都带来了额外的复杂性。它不仅要保存代码，还必须检入系统。每个主要版本控制系统都有工具可以轻松检查代码，而且很多都将直接与IDE集成。但是，这并没有改变保存代码文件时必须采取的其他步骤这一事实。在版本控制系统中放置代码会产生开销，但是在发生问题时回滚到工作代码可以弥补这些额外的开销。
答案 38 :(得分：0)
考虑这种常见情况，例如，修复程序在几个月的时间内应用于某些不稳定的功能“A”。开发人员在这几次尝试期间编辑了多个文件，虽然功能“A”得到了修复，但另一个功能“B”被破坏了。这通常在一段时间后实现，并且只能回想起功能“B”在某个时间点正在工作。在存在版本控制的情况下，所有开发人员必须完成的工作是完成先前的修订并达到破坏“B”的修订版并且只撤消这些部分。使用简单的除法和规则来达到错误版本会使它变得如此之快（如果当前版本是2000，检查1000 - 如果它在那里工作，那么检查1500 ......）。
在没有版本控制的情况下，开发人员必须至少认为关于如何使其再次工作，因此必须花费新的时间在完成时间的事情上花费。现在，这可能是项目中很多功能之一，甚至单个开发人员也可能忘记确切的规范。那么，需要进行规范查找，什么不需要？
我有很多次想要在一个他们正在工作的项目中没有使用版本控制的一些经验丰富的开发人员，后来我不得不对同一个项目应用一些修复。一个这样的开发人员过去常常感到懒惰设置SVN并维护它，而且他不会告诉我什么时候我会问他它究竟是如何工作（当我被分配工作时）因为他会忙于其他一些项目。
懒惰是人类常见的弱点。任何人都可以感到懒惰。我敢打赌，大多数人在重新思考已经在另一种情况下已经完成的事情（没有版本控制）时会感到懒惰或者更加恼怒。那么，哪一个更好？之前是懒惰，或者之后是聪明和懒惰。
答案 39 :(得分：0)
除了设置时间外，源代码控制不会花费任何费用。这只是一个明智的选择。
答案 40 :(得分：0)
是的，即使您是唯一的人源控制也是必须的。当然，你不会用它来控制谁正在处理哪些文件，但是如果你在代码中犯了大错，就能够回复角色真是一件容易的事。
答案 41 :(得分：0)
Subversion对小组来说并不过分，但不应该被认为是对正确项目管理的替代。长话短说 - 如果人们没有时间表和正确的沟通，那么使用版本控制并不是更好，不能使用并且可能导致比它要解决的问题更多的问题。在实施版本控制时应该回答的问题：
答案 42 :(得分：0)
来源控制是。 颠覆NO
Subversion适用于需要很好地处理分支的非常复杂的东西。否则，学习和维护它是不值得的。
还有很多其他更简单的源代码控制（我个人推荐PerForce）
BTW我会排名创建一个构建系统比版本控制更重要。
现在，由于人很少， IS 可以通过仔细拆分您的工作文件来管理源代码控制，但这并没有为您提供版本控制（基本上自动内置到任何源代码控制中）会发现） 至少，您需要能够在几周内回顾并查找文件的版本。
答案 43 :(得分：0)
Visual SourceSafe是一个选项吗？我是一个单独的程序员，并且在最后一次使用它作为一个存储库，没有任何问题，但我一直听到恐怖故事。真的那么糟糕吗？
答案 44 :(得分：-2)
我试图成为第一个回答NO的人。学习如何有效地使用它需要时间。它可能会让新用户感到困惑。滚回来？将您的更改合并在一起？能够分支您的项目？或者确定你现在删除的所有这些东西都不会永远丢失？它只在少数情况下有用，而且我不是100％确定找到SVN或TortoiseSVN并下载它需要10分钟，+ 30分钟来学习一点使用是值得的。
OTOH：是的。您的。伙伴。 *）及;％$＃。疯？我们有几种可能的工具供工作使用。没有广泛的支持CVS或SVN，而是大多数事情的商业亲戚.. 我在我的电脑上使用tortoiseSVN来处理我自己的WORD文档和电子表格，我发现当其他人编辑我的电子表格并将它们发回给我时，MERGE功能确实很有用。 （我倾向于通过将不同版本保存为xml电子表格来进行合并。） 或者在我在多台PC上使用文档或电子表格时备份更改。
然而，关于它的ARGUING不起作用。向她/他展示如何安装它，并演示对同一文档的一些编辑。或者让他们在software carpentry训练自己。