我的团队为什么要采用源代码pipe理？
我有机会正式向我的老板介绍任何有利于公司的事情。 我的想法是在我的工作场所采用源代码pipe理。 我一直在使用Mercurial来pipe理自己的项目，但是其他的团队没有正式的源代码控制系统。 不幸的是，我不擅长提出想法。
那么，你们能告诉我为什么开发者必须使用源代码控制吗？ 另外，为什么你会select除 Visual SourceSafe 之外的任何工具？ 我没有使用VSS的经验，但他可能会问为什么我们不会只使用微软的工具。
我想听听这里很多聪明的程序员的意见！ 我的首选选项是SVN或mercurial。 两者似乎都对Windows版本有很好的支持，并且都不如CVS陈旧。 另外，作为一个自称开源的弟子，我宁愿build议一个开源工具。 🙂
谢谢！
编辑 ：为了简短起见，一般来说，其他开发人员目前的做法是复制文件夹，标签与date，也许自己logging。 你得到的照片。 如果我的老板说“如果有效，为什么要修理呢？”
我们来比较两个例子，一个使用源代码控制的开发环境，另一个没有。
- 答：是否使用
- B： 不使用
场景1：项目被请求，完成并推出
A + B）程序员在内部开发项目，完成后推送到testing，然后交付给客户（无论是谁）
没有太大的区别，在大的图景
情景2：项目发布后，客户端决定不需要functionX.
A + B）开发人员删除客户不想要，testing和交付的代码。
再次，没有太大的区别。
情况3：两个星期后，客户决定他们确实想要Xfunction
A）开发人员将他们在2中取出的代码重新集成到正常的开发树中，testing和交付。
B）开发人员在其个人计算机，文件服务器和备份上search旧代码。 如果他们find代码，他们必须手动重新插入每个文件。 如果他们不这样做，他们可能不得不重新编码整个function。
很容易得到你以某种原因拿出的旧代码
场景4：系统中有一个奇怪的错误，其中一个函数应该返回一个布尔结果，但总是返回false。 两周前不是这样的。
A）开发人员检查软件的所有旧版本，并找出返回虚假指令不在适当的范围内 – 它在循环内而不是在外部执行。
B）开发人员花费数周来试图找出问题所在。 最终，他们注意到错误的回报，并修复它。 没有源代码pipe理意味着他们必须检查每个被执行的文件，而不是从工作时间和现在时间上找出差异。
情景5：有人打破了构build。 它通过testing，只有几个星期后才被注意到。
A）团队检查提交历史，找出谁打破了构build，使该人修复并购买团队晚餐。
B）团队必须通过整个项目来找出错误，但是不知道是谁把代码放在哪里。开发人员相互指责，团队dynamic失败。
很容易看出谁做了什么，什么时候，为什么。
使用源代码pipe理，因为你和你的团队都不是完美的。 源代码pipe理的主要function是确保您拥有完整的开发过程的历史logging。 有了这个logging，你可以自信地用“实验性”版本分支出来，知道如果实验失败了，你可以备份到早期版本。
另外，像svn这样的好的源代码控制系统将允许多个开发者在同一个文件上工作，并提供强大的工具来协调每个引入的差异。
简单地说 – 所以你有一个真实的代码历史 – 调查变化（错误的原因），恢复到版本，审计等备份是不够的 – 你只是有一个当前图片的副本。 有没有改变一个文件，并希望你能记得你做了什么？
出于这些原因您必须使用源代码pipe理
1）你可以回滚到任何版本
2）不同的开发人员可以使用相同的文件
3）所有的开发人员将有权访问相同的代码库
4）您可以跟踪更改
5）您可以回滚不起作用的更改
6）源头控制是持续集成的基础，可以与TDD大规模地协作
7）如果你不使用源代码控制，你会慢慢发疯，因为文件丢失/覆盖，没有任何工作，因为它应该
VSS不是最糟糕的SCC应用程序，我使用了它多年，越来越讨厌它，但它确实工作，很简单，许多人知道它。
微软（MSDN）有一个关于源代码控制的好处的好文章。
http://msdn.microsoft.com/en-us/library/ms173539.aspx
对于正反两方面，这里也有很多很好的问题。
使用之后，你的git的优缺点是什么？
Subversion非常stream行，但Git将成为源代码控制领域的“下一个重大事件”。
这是一个简单的现实生活中的例子。
几年前，我的老板说：“特征XYZ曾经工作，现在不行，没有人知道发生了什么，你能修好吗？
现在我从来没有使用functionXYZ之前。 所以修正它会涉及到很多徘徊在试图弄清楚它是什么。
但是我们有源代码pipe理！ 所以我这样做：
- 创build一个testing脚本来testingfunctionXYZ：“点击这里，input这个，点击那里，等等”
- 获取当前版本。 build立。 testing。 functionXYZ已损坏。
- 从一周前获取版本。 build立。 testing。 functionXYZ的作品。
- 在这两者之间获得版本。 build立。 testing。 functionXYZ的作品。
- 在前一个和当前之间获得版本。 build立。 testing。 functionXYZ已损坏。
我一直在做这种二分search，直到最终我达到了改变的地步：版本145（我们会说）有function的工作，但版本146已经打破。 然后，我只是做了比较这两个版本，看看有什么改变。 原来我们的技术领导（ 叹气 ）检查了代码，改变了function，但也引入了一个副作用，打破了functionXYZ。
所以我删除了副作用，testing了……并且看，特征XYZ再次工作。
没有源代码控制，你永远不能做到这一点。 你将不得不四处乱转，改变这个或那个东西，希望神奇地击中让XYZ再次工作的东西。
通过源代码控制，您只需在版本中进行testing，找出造成问题的确切代码并进行修复。
在我看来，大多数人已经涵盖了源代码pipe理的主要特点，但最大的积极因素之一是跳过了。 这些是：
分行
如果没有源代码库，就不可能为特定目的创build代码的分支（或拷贝/stream/等）。 不能创build和合并分支是最大的事情之一，使VSS不能成为一个真正的源代码控制系统。 一个分支的一些目的包括：
错误修复
有时你需要解决一个错误，并在你的代码的主线或中继版本的地方。 这可能是为了解决testing环境中的一个问题或许多原因。 如果你有一个版本控制工具，你应该能够轻松地创build一个新的分支（VSS吸取的东西）来修复这个bug，并且如果有必要的话可以把它合并回主线代码
维护版本
这可能与错误修复相同，但在代码发布到生产之后完成。 例如修复包，服务发布等。同样，如果需要的话，您希望能够将更改合并回主干
新function
有时您需要在维护当前代码的同时开始新版本的开发。 例如，您发布和维护v1.0，但需要在维护v1.0的同时开始使用v2.0。 分支机构有助于解决这种情况
标记/标签
源代码控制系统所做的另一件事是在特定的时间点对源代码进行快照。 这些在VSS中被称为标签，在颠覆中的标签等等。通过定期创build这些标签，并将它们链接到项目中的一个重要的里程碑，就可以确定代码之间发生了什么变化。 这对于审计人员来说很重要，但也可以追踪问题的来源/范围。 VSS也在这里失败，因为VSS只版本文件，而不是目录。 这意味着如果您重新命名/移动/删除存储库中的文件或目录（如果您重构的话会发生很多事情），则不可能重新创build系统的先前版本。 像Subversion这样的好的源代码控制系统就是这么做的。
我build议使用SVN，因为：
- 源代码控制给你优秀的历史。 你可以看到已经做了什么改变，从而提供了一个很好的方式来看看随着时间的推移发生了什么变化（如果你每次填写提交摘要更好）
- 对于开发者来说，如果出现可怕的错误，它会提供极好的回退。 你可以将文件的变化恢复到历史中的任何一点，这样你就可以尝试你想做的那个mod，如果不行的话，可以很容易地把它滚回去。
- 它提供了一个中央存储库，比备份到不同开发人员的计算机更容易备份。
- 它允许您以不同的方向分支项目 – 对于专业化和自定义有用。
- 它使多个开发人员能够在同一个项目和同一个源代码上通过合并或以其他方式操作对一个中央副本的更改。
我build议不要使用VSS – 请参阅此页面的原因： http : //www.highprogrammer.com/alan/windev/sourcesafe.html更多的原因。
拥有一些版本控制系统可以在很多情况下提供帮助：
单一开发者，单个分支
-
每个版本控制系统如果想要自己调用版本控制，都必须完成的最基本的任务是能够返回到指定版本的项目。 如果你把事情弄得一团糟，你可以到以前的版本。 您可以检查一些以前的版本，以检查它是如何完成的（例如重构之前或删除某些代码/文件之前的样子）。
版本控制系统比使用指定date保存备份副本占用的磁盘空间要less得多 ，因为它们使用增量（仅存储与以前版本的差异）和压缩。 通常备份系统是存储项目的最后N个版本的手段，有时N = 1（仅以前的版本），而版本控制系统（VCS）存储项目的所有历史logging。 在删除第N个版本之后，知道了Murphy，你会意识到这是你想要检查的版本。
另外回到最后一个版本很容易和自动化。 您还可以检查单个文件在过去的版本中的样子，您可以在当前状态和过去的某个版本之间获得差异（以差异格式）。 您还可以标记 （或“标记”）版本，因此您可以不仅按date，也可以从当前版本的第n个版本引用过去的版本，还可以使用符号名称（例如
v1.2或v1.2-rc0。 -
使用版本控制系统，您可以检查历史logging，以提醒您为什么（以及如何）某段代码（给定文件的某个部分）到达当前状态。 大多数VCS允许检查文件的逐行logging，即在文件的每一行更改时，在什么提交和哪个（命令根据VCS被命名为
annotate，blame或praise）时注释它们的每一行。 在一些VCS中，你可以search一个版本（修订）的历史logging，这个版本引入了给定的代码片段（例如，在Git中称为“镐头search”，VCS之一）。为了使这个function真正有用，你必须保持一定的纪律：你应该描述每个新版本（每个新版本/每个新的提交），写下为什么进行更改。 这样的描述（提交消息）是非常有用的，但是它在备份系统中没有自然的地方。
如果你不是唯一的开发者，这个function当然更加有用…
-
使用版本控制系统允许在代码中查找错误的替代方法，即通过search历史find引入错误的版本： 二分历史 。 当你发现引入了bug的版本时，你将会限制（在最好的情况下：非常有限的）区域来searchbug，因为在最后的工作版本和第一个版本之间的差异是一个bug。 你也可以描述一个改变（一个提交信息）来提醒你你想做什么。 这个function有时也被称为diffdebugging 。 现代版本控制系统（VCS）支持自动 （或半自动）通过平分（历史logging分成两半，找出哪个部分包含缺陷，重复直到发现单个负责版本）来search历史logging，以二等
bisect或类似的）命令。为了使这个function真正有用，你必须保持一些纪律：你应该提交（保存更改/把版本控制系统中的给定状态记住）单个更改，只处理一个function，与以前的版本只有很小的差异; 即经常提交。
-
大多数版本控制系统提供各种钩子 ，例如允许自动化testing或产品的自动化构build……或者仅仅提醒您不遵循编码标准（编码指南）。
单个开发者，多个分支
-
版本控制系统允许创build多个交替的并行开发线，称为分支（或stream或视图）。 常见的情况是有开发分支 ，即有不稳定的开发单独的分支（testing新的function），单独的分支稳定（主干，中继版）是（或应该是）当前的工作版本，一个更多的单独维护）分支机构。
拥有维护分支机构，您可以执行错误修正并生成服务包/次要版本，并对某些发行版本进行更正，而不必担心新开发的干扰。 之后你可以把maintenace分支合并到stable中，或者从维护分支中selectbigfix到stable和development分支（如果进一步/其他的开发没有独立地修正bug）。
-
现代的VCS（这里是现代意味着分支和合并分支很容易）允许进一步，即生成单独的分支工作在一个单独的function（所谓的主题分支 ）。 这使您可以在一个function之间切换到另一个function（不仅从开发新function切换到紧急请求的修补程序）。
-
如果您正在开发基于其他（通常是第三方）产品的源代码的产品，那么您应该使用供应商分支机构 ，以便能够轻松地将供应商的新版本与您所做的更改集成在一起。 无可否认，这不再是纯粹的“单一开发者”案例。
多个开发者
-
如果有多个开发人员在同一个项目上工作，使用版本控制系统会带来更多的优势。 VCS允许并发（并行）开发，而不用担心有人会覆盖您的更改，或者不考虑您的更改。 当然使用版本控制系统是不能代替通信的。
-
上述所有function在多重开发人员案例中都更为重要：检查谁生成了变更，谁最后更改了代码（又名谁打破了构build），发现代码中的错误不是只由您写的。
简单：如果代码不安全，则不存在
Subversion是免费的，比VSS更好，但是VSS肯定比什么都好。
在你说什么之前，找出你的公司为什么不使用源代码pipe理。
一旦你知道为什么，很容易想出源代码控制可以提供帮助的场景。
长时间讨论为什么你应该绝对有源代码pipe理：
版本控制是一个小的开发组（1-2名程序员）所必需的吗？
我从这个线索的评论：
即使你自己正在从事一个项目，你也总是希望拥有某种源代码控制。
有一个变化的历史是至关重要的，能够看到一个代码的状态在任何给定的时间。 有一个回顾项目历史的各种理由，从刚才能够回滚一个坏的改变到为旧版本提供支持的时候，当客户只需要一个补丁修复一个bug而不是升级到一个更新版本该软件。
没有某种源控制是纯粹的疯狂。
就VSS而言 – 肯定比没有好。 这绝对不是最好的源代码pipe理，它是非常过时的，但事实是，它继续为那里的很多公司做这项工作。
如果您的老板决心坚持使用Microsoft工具，请使用Team Foundation Server而不是VSS。 这是一个比VSS更好的系统，它具有很好的function，如集成bug追踪。
如果当前进程正在复制一个文件夹并给它一个date，是不是这样，以至于你得到某种发展历史，所以基本上不是一个简单的源代码控制forms？
所以要回答关于源代码控制的任何批评，你已经在做这件事了。 现在你只需要指出当前系统的弱点，并提出一个更好的build议。 当人们真正思考了开发过程中可能出现的很多复杂场景，并开发出让他们处理这些场景的工具时，为什么还需要重新发明轮子。
你现在做的事情是非常脆弱的，如果出现任何复杂的情况，那么你将不得不花费大量的精力去研究如何做一些工具已经做的事情。 VSS比你所做的要好，但是没有SVN，git或者mercurial这样的有用的约定，允许多个项目以一种组织良好的方式一起生活 – 我正在谈论分支，标签和合并其中很脆弱，基本上是vss下的恶梦。
SVN确实有Visual Studio的插件。 有些是免费的。 但是我发现乌龟什么也不吃。 我发现插件的唯一好处是新文件自动添加到svn。
所以，你目前系统的弱点：
- 如果您必须对文件进行更改，则可能会被其他开发人员的更改覆盖或覆盖。 你甚至可能没有注意到这一点。
- 如果你必须记住你已经修改了哪些文件，将它们复制到某个“主”副本上，那么在某个时候你可能会错过一个。
- 祝你好运，find有关你什么时候做出改变的原因，以及为什么。
- 你怎么能在你现有的系统上build立一个稳定的自动化构build系统？ 巡航控制和哈德森工作非常好，你蹒跚自己
- VSS不会将更改分组到多个文件很好。 现代一切都做得非常好，primefaces一致性。
- VSS分支和合并支持是可怕的。 当我们使用它时，我们最终将源代码中的注释括起来，手动复制代码而不是依靠VSS合并。
- 在现有的系统中，要在现场维护中使用某些版本的代码，以及在其他版本（更高版本）中进行大量开发，将会非常困难。 考虑如何保持两个项目同步，需要一个好的工具。 SVN可以做到，git可以做得很好。
这可能足以继续下去，可以做更多。
从我身上拿走， VSS吹 。 这是基本的文件存储w /历史。 什么都比VSS好，VSS比没有好:)
为什么要进行正式的演示？
假设团队规模至less为两个，请做一个现实世界的例子：让两个（或更多，越多越好）的人获得代码，进行修改，并展示如何使用任何非源代码控制来整合所有这些更改意味着你使用。
然后使用源代码控制执行相同的scheme。
通过使用源代码控制所节省的时间和痛苦将会说明问题。
坚持底线，解释它与金钱的关系，你的老板可能会听。
如果你只是一个程序员，我认为主要的观点是你会浪费时间（也就是金钱）来修复简单的错误，试图回滚代码变成错误的想法等等。
如果你是一个以上的程序员，那么以上两次加上这是唯一能够在相同的代码库上一起工作而不浪费更多时间等待彼此的理智方式，
Visual Source安全性总比没有好，但是几乎在每个方面都有更好的免费选项。 如果你的老板需要一个演示文稿来理解为什么源代码pipe理是必不可less的，他可能不会在意你使用了什么工具。 你有其他工具的经验，而不是vss再次涉及的底线，这样就足够了。
我真的很抱歉，但是如果你真的需要在开发环境中争论源代码控制的forms化，那么你处于绝望的境地。 如果你的老板确实需要确信源控制是值得的努力，那么你的老板根本不适合做一群软件开发人员的经理。 为了让人有效地pipe理，他们至less需要对景观有一个基本的了解。 我甚至无法想象当你真的需要争辩一些值得争辩的事情并做一个演讲时会发生什么事情。
没有源代码控制的开发就像开车没有rest。 你失去了进行无缝并发开发的能力，你失去了在工作副本中备份的代码，你失去了通过代码注释进行历史研究的能力，你失去了看到伴随离散变化的上下文和评论的好处，你只是失去，期限。 使用源代码控制是如此明显，有很多好处，这是令人震惊的，你必须certificate它。
在工作中，我们使用颠覆，但一些开发人员（包括我自己）通过git-svn桥本地使用Git。 对于个人工作，我使用Git。
那么，你们能告诉我为什么开发者必须使用源代码控制吗？
- 它为整个团队提供了一种方法。 每个人都按照“基本规则”运作。
- 变化是有序的与混乱的，节省开发时间。
- 跟踪变化的能力促进了问责制，并且更容易find合适的人去解决维护的材料中的问题。
- 可以快速轻松地生成所做的确切更改列表，从而更轻松地向用户提供有关如何从版本更改为版本的信息。
- 如果在更改期间发生严重错误，则很容易“回滚”到较早版本的信息。
源代码pipe理就像保险！ 你希望你永远不需要它，但是当你这样做的时候很高兴你拥有它！
为什么你的团队不应该采用源代码pipe理？
即使作为独奏开发者，我也使用源代码控制。 在现代的软件开发环境中，我可以想到如果有什么原因你不会使用源代码控制的原因很less。 更令人惊讶的是，你还没有拥有它。 这个问题让我觉得像房子画家一样问：“我们为什么要采用梯子，你知道，梯子不能把房子画上 – 画笔就是这样。”
我们使用版本控制的主要原因是consistentency。
如果项目不一致，那么问题就会发生，代码将会丢失。
确保你已经买下了其他的团队。 也许你可以testing你的演讲呢？ 希望他们也看到需要。
很高兴看到自下而上的良好做法。 也许每个人都会更有可能采取这种做法，如果它来自他们自己的做法，而不是一些pipe理任务。
说服pipe理层投资最简单的方法时间在SCCS是关注于备份和存档。 通过使用像Subversion（SVN）这样的东西，您可以立即将任何项目恢复到任何时间点。 没有必要让某人查看备份磁带或担心跟踪多个版本在一个钝的目录结构。
显然还有很多其他优点（即同时在同一个文件上工作的2个人），但备份是多年前我公司迅速销售的。
因为：
-
它将降低成本 – 开发人员将花费更less的时间检查实际VCS中的项目，而不是使用当前的临时方法。
-
它将保护组织的知识产权 – 这应该是任何软件公司最重要的考虑因素（数据除外）。 你付出创造软件 – 不应该是整体访问？
-
它将提供更快，更可靠和直接的备份机制 – 所有的VCS都具有内置的倾卸function。 这些往往比简单的文件复制更成熟。
-
它将充当开发人员之间的沟通机制 – 取决于版本控制系统，您可以使用注释/标签/签出状态来确定是否有其他人在文件上工作，是否已升级到生产，是否具有相应的支持票号等
-
它简化了开发 – 比较版本的文件以及其他机制的能力将有利于您的公司时期。
为了避免这样的事情
"Hey! What happens ? It worked yesterday."
其他人提到了其他地方的源控制的具体好处，但是我想明确地解决这个问题的“VSS”部分。
如果您的老板想要使用Microsoft工具，Team Foundation Server与Team Suite是一个非常好的组合。 它还包含其他工具，如错误跟踪，文档和报告function，这是一个很好的平台，以便以后改进您的过程。 我们工作的地方很开心，同事也告诉我有关VSS的恐怖故事。
记住TFS是对“Microsoft工具”问题的回应。
