为什么我应该使用版本控制？
我正在读博客，作家这样说
“代码不存在，除非它被检入到版本控制系统中，使用版本控制你所做的一切，任何版本控制，SVN，Git，甚至是CVS，掌握它并使用它。
我从来没有使用任何forms的版本控制，我不觉得这很好。 我已经用googlesearch过了，但是如果你愿意的话，我只需要把它放在孩子的条件下。
正如我现在所理解的，像SVN这样的东西是用于在线存储你的代码，以供一组用户或其他开发者访问相同的代码。 一旦你更新了一些代码，你可以提交新的版本，SVN将保留旧代码的副本以及你更新的新代码。
这是它的基本思想还是我完全错了？
如果我是对的，那么如果我：
- 没有其他人在编写代码。
- 不要让别人拥有代码。
你有没有：
- 改变了代码，意识到这是一个错误，想要恢复？
- 丢失的代码或有一个太旧的备份？
- 必须维护一个产品的多个版本？
- 希望看到两个（或更多）版本的代码之间的区别？
- 想要certificate一个特定的变化破坏或修复了一段代码？
- 想要回顾一些代码的历史？
- 想要改变别人的代码？
- 想要分享您的代码，或让其他人使用您的代码？
- 想看看正在做多less工作，以及在哪里，何时和由谁？
- 希望在不干扰工作代码的情况下尝试新function？
在这些情况下，毫无疑问，一个版本控制系统应该让你的生活更轻松。
误导朋友：一个文明的工具，文明的时代。
即使你一个人工作，你也可以从源代码控制中受益。 其中，由于这些原因：
-
你不会失去任何东西。 我再也没有注释掉代码。 我只是删除它。 它不会混乱我的屏幕，而且不会丢失。 我可以通过签出一个旧的提交来恢复它。
-
你可以随意试验。 如果不能解决问题，请将其还原。
-
您可以查看以前版本的代码，以了解引入错误的时间和位置。
git bisect在这方面很棒。 -
分支和合并等更“先进”的function让你有多条平行的开发路线。 您可以在不受干扰的情况下同时处理两个function，而且不必麻烦地来回切换。
-
你可以看到“改变了什么”。 这可能听起来很基本，但这是我发现自己检查了很多东西。 我经常开始我的单人工作stream程：我昨天做了什么？
只要继续尝试就可以了。 慢慢地开始使用基本function，并随时了解其他人。 你很快就会发现，你永远不会想回到没有VCS的“黑暗时代”。
如果你想要一个本地VCS，你可以设置你自己的Subversion服务器（我以前做过的），但今天我会推荐使用git 。 简单得多。 只需cd到您的代码目录并运行：
git init
欢迎来到俱乐部。
版本控制是一个罕见的工具，我会说绝对是必需的，即使你只是把它作为独奏开发者。 有人说这是你生活和死的工具，我同意这个说法。
即使您不知道，也可能使用版本控制。 你有没有说“XXX Php Code（December）”或“XXX.php.bak.2”的文件夹？ 这些已经是版本控制的forms了。 一个好的版本控制系统会为你自动处理。 您将能够回滚到任何时间点（您已签入数据），并能够查看该数据的确切副本。
而且，如果你采用一个像subversion这样的系统，并使用一个远程仓库（比如你所拥有的服务器上的仓库），你将有一个地方来保存所有的代码。 需要你的代码在其他地方的副本？ 没问题，只要检查一下。 硬盘崩溃在家里？ 不是一个问题（至less在你的源代码中）。
即使您现在不使用版本控制，您可能会在以后的某个时间使用版本控制，您可以从现在变得更加适应原则。
即使单独工作，这有没有发生过？ 你运行你的应用程序，有些东西不起作用，你说“昨天有效，我发誓我没有触及那个类/方法。” 如果您定期检查代码，快速版本差异将显示在最后一天发生了什么变化。
这是一个可以说明源代码控制的有用性的场景，即使你一个人工作也是如此。
您的客户要求您对网站实施一个雄心勃勃的修改。 这将需要你几个星期，并涉及到许多页面的编辑。 你开始工作
当客户打来电话时，你完成了50％的工作，并告诉你放弃你正在做的事情，以便对网站做一个紧急而又微小的改变。 你没有完成更大的任务，所以还没有准备好上线，客户也不能等待更小的改变。 但是他也希望把这个小小的改变融合到你的工作中去，以便做出更大的改变。
也许你正在一个包含网站副本的单独文件夹中处理大型任务。 现在你必须弄清楚如何以一种可以快速部署的方式进行微小的改变。 你疯狂地工作，把它完成。 客户端callback进一步的细化请求。 你也这样做，并部署它。 一切都很好。
现在，您必须将其合并到正在进行的重大变更中。 紧急工作你换了什么？ 你工作得太快，不能记笔记。 而且现在你不能轻易地对这两个目录进行分析，而这两个目录相对于你开始的基线都有变化。
上面的场景表明，即使你单独工作，源代码pipe理也是一个很好的工具。
- 您可以使用分支来处理较长期的任务，然后在分支完成时将分支合并回主线。
- 您可以将整套文件与其他分支进行比较，也可以比较过去的修订版本，以查看有什么不同。
- 您可以随时跟踪工作情况（顺便说一下，这对于报告和开票非常有用）。
- 您可以根据date或在您定义的里程碑上恢复任何修订版本的文件。
对于单独的工作，build议使用Subversion或Git。 任何人都可以自由select其中的一种，但显然要比不使用任何版本控制要好。 好书是Mike Mason的“ 使用Subversion的第二版 实用版本控制 ”或Travis Swicegood的“ Pragmatic Version Control Using Git ”。
原作者： Bill Karwin
即使单个开发者源代码pipe理提供了很大的好处。 它允许您随时保存您的代码的历史logging并恢复到以前版本的软件。 这让您无所畏惧的灵活性进行实验，因为您可以随时恢复到正在工作的另一个版本的源代码。
这就像有一个巨大的“撤销”button一直回到你的第一行代码。
开始使用版本控制几乎是不可能的。 如果不止一个开发人员正在使用相同的代码库，这是必不可less的，但对于单个开发人员也是非常有用的。
它跟踪代码中的更改，并允许您回滚到以前的版本。 它释放你试验的知识，如果有什么突破你可以撤消你的改变。
您可以获得安全性（就代码的备份而言）和代码版本（假设您习惯于经常进行更改）。 即使没有其他人结束与你的代码工作，两者都是非常好的事情…
版本控制对于检查以前的版本是很好的，即使你一个人工作。 例如，如果您不小心删除了代码或文件，则可以将其还原; 或者你可以比较以前的版本，看看为什么一个新的bug已经悄悄进入。如果你是一个人在多个地点工作也是很好的。
我个人最喜欢的是git。
使用版本控制有很多原因，即使您是唯一一个会触摸代码的人。
- 备份 – 如果硬盘驱动器崩溃怎么办？ 你有没有复制到任何地方？
- 修订历史logging – 您目前是否将代码副本保存在不同的文件夹中？ 通过版本控制，您可以随时追踪您的更改，并使用工具轻松区分不同的版本，合并，回滚更改等。
- 分支 – testing一些变化的能力，仍然追踪你正在做什么，然后决定是否要保留它并合并到主项目中，或者把它扔掉。
如果您将代码保存在版本控制之下，那么可以很容易地看到哪些文件已经更改（或已经忘记添加到基线）。
其他人似乎没有明确提到的是发布的标签或标签。 如果你有一个客户使用你的软件的版本1，而你正忙于版本2，那么当客户报告一个错误并且你需要build立版本1.1时，你会做什么？
一个源代码pipe理系统可以让你标出每一个发布的版本，所以你可以稍后再回到这个版本，进行修复（并且把修补程序合并到新的版本2代码中）并且发布一个新的版本，而不用担心你可能会意外地没有准备好。
源代码控制是现代软件开发的核心部分。 如果你不使用它（甚至对于个人项目，因为你有更好的经验），你做错了什么。
我通常在面试时遇到的第一个问题是“你用什么来控制源代码？” 到目前为止，只有一个地方说“什么都没有”，但是他们正在计划修正“真的很快……”
其他开发者参与或不参与的事实完全正交于版本控制系统的需要。
您可以成为唯一的开发者，但仍然会受益于：
- 所有更改的历史logging
- 在这段历史上前进的能力
- 能够尝试源代码，同时仍然有一个工作版本（分支）
- 一个备份副本（尤其是如果您使用不同的机器作为源控制服务器，甚至更多，如果该机器定期备份）
现在，如果你有一个开发团队在同一个代码库上进行版本控制，那么更为必要
- 人们可以同时编辑相同的文件（取决于特定的系统，但最正常的允许你这样做）
- 你可以告诉谁在什么时候对代码做了什么
当涉及更多的人时，根据开发的风格，select哪个版本控制工具更为相关。
它也是关于备份旧文件，为什么它被称为“颠覆”。 所以你可以pipe理你的工作的多个版本，你可以返回（恢复）和pipe理它的不同实现（分支）。
你可能会发现你有一个你的程序的工作版本。
您决定在一段时间内添加一些新function，然后释放该function。
你开始得到错误报告，影响你认为你没有触及的一些代码。
例如，通过使用SVN，您可以移回旧版本，并检查是否存在新的错误。 一旦find引入bug的版本，就可以更容易地修复它，因为您可以比较工作的版本和没有工作的版本，并查看更改的内容，然后缩小search范围。
源代码控制有很多用途，即使你是唯一的开发者。
听起来你正在寻找更轻量的东西。 看看Mercurial（ 真棒参考书 ）。 我用它来做一切事情，从源代码到个人信件。
一些好处：
- 巨型撤销button，所以你可以返回代码实际运行的上周那些平静的日子
- 扔掉代码。 不知道这是做最好的方法吗？ 做一个分支和实验。 没有人，但你必须知道，如果你正在使用像一个DVCS像汞。
- 同步发展。 我在4台不同的电脑上开发。 我推他们之间保持目前，所以不pipe我在哪一个我有最新的版本。
即使您尚未处于需要较旧版本程序的情况下，拥有源代码pipe理function也可让您更有信心进行重大更改。
在使用源代码控制之后，我发现自己做了更积极的重构，因为我总是知道可以轻松地恢复工作版本。
这取决于项目的规模，以及你多久改变一下自己的想法。 对于那些刚刚以线性方式完成某些事情的小型项目来说，版本控制可能不会有太大的帮助（尽pipe如果不小心删除或损坏了没有版本控制的文件，您将会哭泣）。
但几个星期前，我遇到了一个自己正在写一个巨大的爱好项目的朋友。 他有十或二十个他的代码副本，后缀如“X1”，“X2”，“testing”，“更快”等等。
如果您制作了两个以上的代码，则需要进行版本控制 。 一个好的版本控制系统可以让你取消你之前做的改变，而不用撤销你在改变之后所做的改变。 它可以让你看到什么时候做了某些更改。 它可以让你把你的代码分成两个“path”（例如一个用于testing一个新的想法，另一个用于保持你的“可靠和可信”的代码安全，直到你完成testing）然后合并到一起。
我也只是最近才开始对版本控制感兴趣。 在版本控制系统中，您拥有代码库的概念。 大量新的shell命令可以快速学习，以便您可以与此存储库进行交互。
一旦将代码保存到文件中，就可以将其提交到项目的存储库中。 在您开发代码并提交您的更改时，存储库会进行一系列修订 。 您可以通过检查修订来访问其中的任何一个。 如果你单独工作，那么除非你丢失了你的代码文件，或者想在另外一台机器上工作，否则你不太可能会做很多检查。 在这些情况下，您通常会查看所有文件的最新版本。
对于我自己来说，当我决定重构某些东西时，我不再保留名为“project_old”的文件或文件夹。 我所做的任何修改都是逐步存储的，而且我总是可以退后一步到一个整体工作的项目。 我现在很less使用FTP来部署，因为我只是通过ssh检查我的代码。 只有我更改的文件被下载，如果我需要在服务器上重新加载terminal已经在那里。
我发现这个关于GIT的谈话真的很有启发性。 http://www.youtube.com/watch?v=4XpnKHJAok8
这是一个谷歌谈话，其中Linus Torvalds使用一个版本控制系统而不是另一个。 在这样做的时候，他解释了他们如何使用概念，然后比较不同的实现方式。
即使你自己工作，你也可能想要一些类似颠覆的东西，这样你就可以logging所有的变化。 你可能想看看一段代码看起来像什么样子，以记住你为什么做了一个改变。
有经常检查的源代码pipe理也很有用。 如果你经常办理登机手续，你总是会经常回滚。 很多时候，你可以开始沿着一条path解决问题，然后意识到这是一个错误的path。 很多时候，你可能只是不停地在错误的道路上吠叫，最终build立一个可怕的解决scheme – 只是因为你不想失去所有的工作。 通过经常入住，“幸福”的最后一点并不遥远，所以即使你走错了路，也总是可以回滚一遍，做一个更加优雅，简单的解决scheme。 这总是一件好事，所以你可以理解和维护你将来写的东西。
