我真的需要版本控制吗？
我阅读了所有关于版本控制的互联网（各种网站和博客）。 这是多么伟大，以及所有开发人员如何使用它，因为它是非常有用的。
这是一个问题：我真的需要这个吗？ 我是前端开发人员（通常只是HTML / CSS / JavaScript），我从来没有像“哇，我昨天的文件！”的问题。 我试过使用它，安装Subversion和TortoiseSVN ，我理解版本控制背后的概念，但是…我不能使用它（怪异的我）。
好的，那么…那很糟糕吗？ 我通常一个人工作（自由职业者），而且我没有要求我使用Subversion的客户（但是不要太晚，对不对？）。 那么，我是否应该开始努力学习使用Subversion（或类似的东西？），或者只是浪费时间？
相关问题： 好的借口不要使用版本控制 。
这是一个可以说明源代码控制的有用性的场景，即使你一个人工作也是如此。
您的客户要求您对网站实施一个雄心勃勃的修改。 这将需要你几个星期，并涉及到许多页面的编辑。 你开始工作
当客户打来电话时，你已经完成了50％的工作，并告诉你放弃你正在做的事情，以便对网站做出紧急的但更小的改变。 你没有完成更大的任务，所以还没有准备好上线，客户也不能等待更小的改变。 但是他也希望把这个小小的改变融合到你的工作中去，以便做出更大的改变。
也许你正在一个包含网站副本的单独文件夹中处理大型任务。 现在你必须弄清楚如何以一种可以快速部署的方式进行微小的改变。 你疯狂地工作，把它完成。 客户端callback进一步的细化请求。 你也这样做，并部署它。 一切都很好。
现在，您必须将其合并到正在进行的重大变更中。 紧急工作你换了什么？ 你工作得太快，不能记笔记。 而且现在你不能轻易地对这两个目录进行分析，因为这两个目录相对于你开始的基线都有变化。
上面的场景表明，即使你单独工作，源代码pipe理也是一个很好的工具。
- 您可以使用分支来处理较长期的任务，然后在分支完成时将分支合并回主线。
- 您可以将整套文件与其他分支进行比较，也可以比较过去的修订版本，以查看有什么不同。
- 您可以随时跟踪工作情况（顺便说一下，这对于报告和开票非常有用）。
- 您可以根据date或在您定义的里程碑上恢复任何修订版本的文件。
对于单独的工作，build议使用Subversion或Git。 任何人都可以自由select其中的一种，但显然要比不使用任何版本控制要好。 好书是Mike Mason的“ 使用Subversion的第二版 实用版本控制 ”或Travis Swicegood的“ Pragmatic Version Control Using Git ”。
有很多好处，是的，你需要它。
- 什么工具/技术可以使独奏开发者受益？
- 单独开发者的最佳版本控制
你不需要版本控制，只需要一个艺术家需要一个安全网。 这就像备份你的硬盘 – 大部分时间似乎是多余的，因为没有任何反应，但最终还是需要它。 这里没有可能。 它会发生。 而且你永远无法预测什么时候和过去是什么时候发生的一个糟糕的指标。 它可能在未来只发生过一次，即使你知道一旦你不知道它会有多糟糕，它会发生。
是!
这样做。 它不会伤害你..
我通常从笔记本电脑切换到个人电脑，然后把它放在中央存储库中，这是非常棒的。
有时候回到最新的版本是很好的，因为你搞砸了一些难以解决的问题。
缺less的最大优势是能够重新生成生成旧版本的源代码。
在构build时，用“Build 4.26”标记源代码pipe理。 第二天，你开始编译构build4.27。 三个月后，当一个客户说：“我正在使用Build 4.26，并且Frickershawfunction中存在一个错误。由于在4.27版本中对文件格式进行了一些更改，我无法升级到任何其他版本。你能为我做什么？我愿意付钱。“
然后，您可以检出4.26源代码的一个分支…修复Frickershawfunction，然后在一两个小时内为用户重新构build软件包。 然后，您可以切换回到版本4.39，并继续工作。
同样，您可以追踪添加错误的确切位置。 testing版本4.25的错误，然后4.20，然后4.10，最终发现bug 4.12版本引入。 然后，查看“Build 4.11”和“Build 4.12”之间所做的所有更改，然后关注Frickershawfunction。 您可以快速find该bug的源代码，而无需进行debugging。
分支对你来说似乎没有用处？ 你从来不想试一试，看看它是否会奏效？ 我也做了很多简单的旧的HTML / CSS的东西，我觉得这是非常宝贵的。 在分支testing一些东西，看它是否有效，决定“meh”，然后回滚，几乎没有任何危险。
我从来没有需要得到一个备份（敲木头），但我发现只是回滚function非常宝贵。
作为一名自由职业者有一些特权：
- 明确地知道你在每一个文件中改变了什么，何时（只要你经常检查）
- 回滚到您以前的任何版本。 令人惊讶的是这多么有价值。
- 跟踪一组更改为“发布”。 这样你就知道每个客户当前正在使用什么和正在开发什么。
- 备用
- 如果你突然不是独奏，就可以轻松地共享一个项目
试试像Git或Bazaar DVCS 。 它们非常容易设置，易于使用，并提供Subversion，CVS等所有重要function。
关键是，当你破坏某些东西时，你可以恢复到工作版本，这通常要比手动撤销更快的速度。
如果没有他们整合到我们的stream程中，我不会雇用一个承包商。 他们将不得不通过我们的SVN访问代码，并且不会在没有满足unit testing和代码审查要求的情况下获得付款。
如果签约，我会确保对VSS（签入/签出）和CVS（合并与冲突）模型有丰富的经验。
自己工作，你有一个很好的机会玩和学习最新的 – 我会尝试Git。
作为一名独立的开发人员，您可以将源代码pipe理视为无限制的撤消 – 可以在会话中重新启动。
对我来说，源代码控制的一个小优点是我在多个开发计算机上工作。 在机器之间移动我的工作很容易。
我认为最大的优点已经列出来了。 它让我在晚上睡觉，知道如果我们必须回滚一个变化，这将是相当容易的。
我认为从“保留所有版本的文件系统”转换为源代码控制系统的主要优点在于，sccs为所有这些文件的版本添加了结构，并为您提供了“在X点整个文件系统的一致状态是怎样的”。
换句话说，“哪个版本的文件A与哪个版本的B，C，D …一起”。
而事后（¡）： 提交或检查的特殊行为会让你思考“这是什么？”，并由此产生的日志信息可以作为记忆。
这个问题的文字回答是， 不，你不需要版本控制。
但是，即使您不知道，也要执行WANT版本控制。
也就是说，在突破Grok Barrier之前，许多SCM工具可能会让人感到神秘或彻底的不愉快，所以让我们来修改一下：
“但是，你确实需要易于使用的版本控制。” 而且它在那里……下载一个推荐的视觉客户端，并给他们一个旋转，然后尝试哪个地图最好的方式，你的想法。
这导致了你要问的问题：
我为什么要使用版本控制？“
答： 版本控制可以让你成为FEARLESS！
是的，你需要它。
至less，对于单个开发者商店，您需要将代码每天多次移动到ProjectName-Date-Time目录中。
也就是说，编写一个脚本，可以在午餐和退出时自动备份工作目录，而不会覆盖其他备份。
这可以增长得相当快，所以最终你只想保存文件之间的差异，这是一个VC应用程序。
既然你通常单独工作，我会说使用版本控制是一个好主意。 我在使用版本控制（在我的情况下是Subversion）中获得的一个主要好处是，单独工作时，使我更有信心尝试解决问题的新方法。 你总是可以转向解决问题的新方法或框架，看看你是否更喜欢它。 如果事实certificate这个分支不起作用，你可以放弃它，回到旧的方法。 这也使得更容易地尝试不同的解决scheme并排。
所以，如果你曾经见过不同的解决问题的方法，并且想尝试一下，我肯定会使用版本控制作为一个工具来使这个更容易。
如果您正在自己的工作，并定期执行备份，可能不需要VC（除非您将备份计为版本历史logging）。 一旦你开始与另一个开发者合作，你应该进行版本控制，以免重写对方的工作。
即使你现在不需要它，但是当你在一个团队工作时，这是你需要的。
有一个更改您的HTML / CSS / JavaScript的历史可能是一个天赐之物。 能够比较你的前端和代码一个月，或几个月前，真的可以很长的路要走，找出为什么突然模板是歪斜的。
此外，如果您想要/需要获得项目帮助，则可以使用简单的系统分发，跟踪和部署更新的内容。
一定要这样做，一旦你习惯了，你会感谢你自己。
结帐（一次）更新（一天的开始）提交（任务结束/testing后更改）
这就是它的全部。 不要在浏览器中进行每一次单一的修改，只要你想要上线。
想想它是否像一个备份。 这是有点刺激，直到你需要它的一天。 那么失去的工作量与备份的频率成正比。
另一个好处是能够看到你曾经做过的事情，而这些事情在某个地方可能已经过时了，但在另一个地方却可能有用。 只需剪切并粘贴进行比较时得到的旧代码即可。
那是除非你喜欢重新发明你已经改造的车轮…
当事情可能出错时，他们会。 能够引用一个月前可能已经删除的代码，或者在硬件故障或升级后恢复整个项目，这是非常好的。
未来，当项目进行得比你多时，也可能会有一个问题。 在这样的环境中，防止（或控制）分支和版本控制是必须的。
必须必须必须必须。 您必须使用版本控制。
这是最重要的。
如果你不明白为什么现在，你会有一天。
当你的客户在惊慌失措的电话里，因为现场网站上的某些东西被破坏了，这是一个倒退，你会很高兴你可以打开TortoiseSVN，看看你上周二做了什么导致破坏。
真奇怪 自从我开始使用版本控制以来，我偶尔需要查看旧代码并使用它们。 我以前从来没有必要这样做，可能是因为做的想法并没有真正坚持下去。 当你发现版本控制有帮助时，很容易就不会注意到这些时间。
在整个代码库中search。 这是一个杀手级的function，主要是因为search在另一台机器上运行，所以你可以不受干扰地继续工作。
顺便说一下，这就是为什么我们没有改变到SourceGear Vault的原因。 它不能做到这一点。 我们仍然在寻找SourceSafe兼容的替代品… SourceSafe。 尽pipe每个人都说，但还没有让我们失望*
*这可能只是一个时间问题。
我想你已经做出了使用某种版本控制的正确决定。 为了简单起见，我会使用SVN（忽略CVS，因为SVN基本上是一个“更好”的CVS）
SVN可以直接在文件系统和许多平台上使用“本地”存储库，因此您不必在基础架构（服务器，networking等）
SVN的好资源： http ： //svnbook.red-bean.com
我对GIT不太了解，但是它是开源的，获得大量的分享可能有很多类似的优势！
从某个地方借用一句话：现在你可能不需要它，但是当你这样做时，你会很高兴你做到了。
快乐的版本控制！
尽pipe老旧，我们发现微软Visual SourceSafe工作。 这对保存版本历史logging非常有用。 如果你不担心分支，这是你可能不是的独奏开发者，它可能只适合这个账单。
就检查而言，find一个好的检查点可能是一个挑战，但是检查每次保存只会使版本难以跟踪。
“我真的需要版本控制吗？”
是。 除非你编写完美的代码，永远不需要改变。
一个例子：我有一个要求。 我build立了一个网页，在网页上花了一天左右的时间，这是508节的兼容性（这是大约6 – 7年前），并上传到网站。 接下来，需求发生了巨大的变化。 我花了一天的时间在页面上工作（和Hayuge Excel文件没有转换成易于访问的HTML容易）。 大约一个星期后，客户端交换机要求我们返回到版本A.源代码控制将在大约10分钟内完成。 就这样，我不得不在任务上再次打击％$＃^^＆$＃日。
是的，您需要进行版本控制，无论是为了开发目的还是为了存储文档。 这样，如果您需要这样做，可以及时回过头来恢复代码或文档上的更改或错误。
一旦你开始在一个团队中引用从多个调用者/应用程序升级“组件”，版本控制将是绝对必要的。 在这样的环境下，你无法跟上可能改变的所有变化。
你需要版本控制就像你需要保险的生活。
您需要版本控制来pipe理不同的文件版本。 有了它，您可以从不同的地方获得和处理文件，并且帮助团队成员在同一个项目上进行协作。
