我的团队为什么要采用源代码控制？

Question

我有机会向我的老板正式介绍有益于公司的任何事情。我的想法是在我的工作场所采用源代码控制。我一直在使用Mercurial来管理我自己的工作项目，但团队的其他成员没有正式的源代码控制系统。不幸的是，我不善于提出想法。

那么，你们能告诉我为什么开发人员必须使用源代码控制吗？另外，为什么你会选择除 Visual SourceSafe之外的任何工具？我没有使用VSS的经验，但他可能会问为什么我们不会只使用微软的工具。

我想听听许多智能程序员的意见！我首选的选项是SVN或mercurial。两者似乎都对Windows版本有很好的支持，而且两者都不如CVS那么古老。另外，作为一个自称为开源的门徒，我更愿意提出一个开源工具。 ：）

谢谢！

编辑：简而言之，通常情况下，其他开发人员目前的做法是复制文件夹，标记日期并自行记录。你得到了照片。如果我的老板说“如果它有效，为什么要解决它？”

Answer 1

让我们比较两个例子，一个使用源代码控制的开发环境，另一个不使用源代码控制的开发环境。

• 答：使用
• B：不使用

场景1：请求，完成并推出项目

A + B）程序员在内部开发项目，在项目完成后，将其推出测试，然后交付给客户（无论是谁）

在大图中没有多大区别

场景2：项目发布后，客户端决定他们不需要功能X

A + B）开发人员删除客户端不想要，测试和交付的代码。

同样，差别不大。

情景3：两周后，客户决定他们确实想要功能X

A）开发人员将他们在2中取出的代码重新集成到正常的开发树中，进行测试和交付。

B）开发人员在他们的个人计算机，文件服务器和备份上搜索旧代码。如果他们找到代码，则必须手动重新插入每个文件。如果他们不这样做，他们可能不得不重新编写整个功能。

您可以轻松获取因某种原因而取出的旧代码

场景4：系统中存在一个奇怪的错误，其中函数应返回布尔结果，但始终返回false。两周前情况并非如此。

A）开发人员检查软件的所有旧版本，并确定返回false伪指令不在适当的范围内 - 它在循环内而不是在外部执行。

B）开发人员花费数周时间试图找出问题所在。最终，他们注意到错误的返回，并修复它。没有源代码控制意味着他们必须检查已执行的每个文件，而不是查找它现在和现在的差异。

场景5：有人打破了构建。它经过了测试，仅在数周后才被发现。

A）团队检查提交历史，找出谁破坏了构建，让那个人修复它并购买团队晚餐。

B）团队必须返回整个项目才能找到错误，但无法弄清楚是谁放了代码。开发人员互相指责，团队动态失败。

很容易看出谁承诺了什么，何时以及为什么。

Answer 2

使用源代码管理，因为您和您的团队都不是完美的。源代码管理的主要功能是确保您拥有开发过程的完整历史记录。有了这个记录，你就可以自信地分出“实验性”版本，知道如果实验失败，你可以备份到早期版本。

此外，像svn这样的优秀源代码控制系统将允许多个开发人员处理同一个文件，并提供强大的工具来协调各自引入的差异。

Answer 3

简单 - 所以你有一个真实的代码历史 - 调查变化（错误的原因），恢复到版本，审计等等。备份是不够的 - 你只需要一份当前< / strong>图片。永远改变一个文件，并希望你能记得你做了什么？

Answer 4

出于这些原因，您必须使用源代码管理

1）您可以回滚到任何版本

2）不同的开发人员可以处理相同的文件

3）所有开发人员都可以访问相同的代码库

4）您可以跟踪更改

5）您可以回滚不起作用的更改

6）源控制是持续集成的基础，并且大规模地帮助TDD

7）如果你不使用源代码控制，你会慢慢发疯，因为文件丢失/覆盖，没有任何工作，因为它应该

VSS不是最糟糕的SCC应用程序，我使用它多年并且变得讨厌它，但它确实有效，很简单，并且很多人都知道它。

Answer 5

这是一个简单的现实生活中的例子。

几年前，我的老板说，“功能XYZ曾经工作过，现在却没有。没有人知道发生了什么。你能解决它吗？”

现在我以前从未使用过XYZ功能。所以修复它会涉及很多试图找出它的作用。

但我们有源控制！所以我这样做：

• 创建测试脚本以测试功能XYZ：“单击此处，键入此内容，单击此处等”。
• 获取最新版本。建立。测试。功能XYZ已损坏。
• 从一周前获取版本。建立。测试。功能XYZ工作。
• 在这两者之间获得版本。建立。测试。功能XYZ工作。
• 在上一个版本和当前版本之间获取版本。建立。测试。功能XYZ已损坏。

我一直在进行这种二元搜索，直到最终我遇到了变化：版本145（我们会说）有这个功能正常工作，但版本146已经破坏了。然后我只是对这两个版本进行了比较，看看有什么变化。事实证明我们的技术主管（叹气）检查了更改功能的代码，但也引入了破坏功能XYZ的副作用。

所以我删除了副作用，测试了...然后看，XYZ的功能再次起作用。

没有源代码管理，你永远不能这样做。你将不得不四处走动，改变一件事，希望能够神奇地击中让XYZ再次发挥作用的东西。

使用源代码控制，您只需测试版本，确定导致问题的确切代码并进行修复。

Answer 6

Microsoft（MSDN）有一篇关于源代码控制的好处的文章很好 http://msdn.microsoft.com/en-us/library/ms173539.aspx

关于利弊，这里也有很多好的问题 What are your pros and cons of git after having used it?

Subversion很受欢迎，但Git将成为源代码控制领域的“下一件大事”。

Answer 7

在我看来，大多数人已经涵盖了源代码控制的主要特征，但其中一个最大的好处是被忽略了。这些是：

<强>分支机构

如果没有源代码存储库，则无法为特定目的创建代码的分支（或副本/流/等）。无法创建和合并分支是使VSS成为真正的源代码控制系统的最大因素之一。分支的一些目的包括：

错误修复

有时您需要解决一个错误并在远离代码的主线或主干版本的地方执行此操作。这可能是为了解决测试环境中的问题或任何原因。如果你有一个版本控制工具，你应该能够轻松地建立一个新的分支（VSS很糟糕）来修复bug，并在必要时能够将它合并回主线代码

维护版本

这可能与错误修复大致相同，但在代码发布到生产后完成。示例将是修订包，服务版本等。再次，您希望能够在必要时将更改合并回主干

新功能

有时您需要在维护当前代码的同时开始开发新版本。例如，您发布并维护v1.0但需要在维护v1.0的同时在v2.0上开始工作。分支机构有助于解决这种情况

<强>标记/标签

源代码控制系统所做的另一件事是在特定时间点制作源代码的快照。这些在VSS中称为标签，在颠覆中称为标签等。通过定期创建这些标签并将它们链接到项目中的某个重要里程碑，可以确定发布之间代码中的确切更改内容。这对审计员而言非常重要，但也可以追踪问题的来源/范围。 VSS也因此失败，因为VSS只对文件进行版本控制，而不是目录。这意味着如果重命名/移动/删除存储库中的文件或目录，则无法重新创建系统的先前版本（如果重构，则会发生很多事情）。像Subversion这样的优秀源代码控制系统就是这样做的。

Answer 8

我建议使用SVN，因为：

1. 源代码控制为您提供出色的历史记录。您可以看到进行了哪些更改，从而提供了一种很好的方式来查看随时间变化的内容（如果每次都填写提交摘要，则会更好）
2. 对于开发人员来说，如果出现可怕的错误，它会提供出色的后备。您可以将文件的更改还原到其历史记录中的任何位置，这样您就可以尝试使用该模型，如果它不起作用，请轻松将其向后滚动。
3. 它提供了一个中央存储库，比运行到不同开发人员的计算机更容易备份。
4. 它允许您以不同的方向分支项目 - 对于专业化和自定义非常有用。
5. 它允许多个开发人员在同一个项目和相同的源上协同工作，允许您合并并以其他方式操作对一个中央副本的更改。

我建议使用VSS NOT - 请参阅此页面了解原因： http://www.highprogrammer.com/alan/windev/sourcesafe.html了解更多原因。

Answer 9

Answer 10

如果当前进程正在复制文件夹并给它一个日期，那不是为了获得某种开发历史，那么这基本上不是一种简单的源代码控制形式吗？

所以，为了回答有关源代码控制的任何批评，你已经在做了。现在你只需要指出当前系统中的弱点并建议一个更好的弱点。 当人们真正想到在开发过程中可能发生的许多复杂场景并开发出让他们处理它们的工具时，为什么还需要重新发明轮子呢。

你目前正在做的事情是非常脆弱的，如果出现任何复杂的情况，它将会失败，此时你将不得不花费大量的精力来研究如何做一些工具已经做的事情。 VSS比你正在做的更好，但没有SVN，git或mercurial所允许的非常有用的约定，它允许多个项目以一种组织良好的方式共存 - 我正在谈论分支，标签和合并，两者其中很脆弱，基本上是vss下的噩梦。

SVN确实有visual studio的插件。有些是免费的。但我发现龟甲只会使其他任何东西都黯然失色。我在插件中找到的唯一好处是新文件会自动添加到svn。

因此，您当前系统的弱点：

• 如果您必须对文件进行更改，则可能会覆盖或被其他开发人员的更改覆盖。你甚至可能都没有注意到这一点。
• 如果您必须记住您已更改哪些文件以将其复制到某些“主”副本上，那么您可能会在某个时候错过一个。
• 祝你好好找到关于何时做出改变的文件以及原因。
• 您如何在当前系统上构建稳定的自动构建系统？克鲁斯控制和哈德森的工作非常好，你正在蹒跚学步
• VSS不会将对多个文件的更改组合在一起。现代的一切都做得非常好，具有原子一致性。
• VSS分支和合并支持很糟糕。当我们使用它时，我们最终将每个更改都包含在源代码中的注释中，并手动复制代码而不是依赖于VSS合并。
• 在当前的系统中，要在现场维护中使用某些版本的代码以及其他一些版本，在重大开发中将会非常困难。想想保持两个项目同步所需的东西，你需要一个好工具。 SVN可以做到，git可以做得很好。

这可能足够继续，可以做更多。

Answer 11

长期讨论为什么你应该绝对拥有源代码控制权：

Is Version Control necessary for a small development group (1-2 programmers)?

我对该主题的评论：

  

你永远都想拥有一些   即使你是一种源控制   自己做项目。

     

有变化的历史至关重要   能够看到一个状态   任何给定时间的代码库。有   回顾的各种原因   在项目历史中，范围从   只是能够回滚一个坏人   改为为老人提供支持   当客户只想要一个时发布   补丁修复bug而不是   升级到更新版本的   软件

     

没有某种源代码控制   是纯粹的疯狂。

就VSS而言 - 它肯定比没有好。它绝对不是最好的源代码控制，并且它已经过时了，但事实上它继续为那里的许多公司做好工作。

如果您的老板决心坚持使用Microsoft工具，请选择Team Foundation Server而不是VSS。它是一个比VSS更好的系统，它具有很好的功能，如集成的错误跟踪。

Answer 12

在你说什么之前，找出你的公司没有使用源代码控制的原因。

一旦你知道原因，就很容易想出源控制可以提供帮助的场景。

Answer 13

简单：如果代码不是源安全的，则它不存在

Subversion是免费的，比VSS更好，但VSS肯定比没有好。

Answer 14

从我这里拿走， VSS打击。这是历史记录的基本文件存储。任何东西都比VSS更好，VSS总比没有好。）

Answer 15

  

那么，你们能告诉我原因吗？   开发人员必须使用源代码管理？

• 它为整个提供了一种方法 团队使用;每个人都在 同样的“基本规则”。
• 变化是 有序与混乱，节约 发展时间。
• 跟踪的能力 变化促进了问责制 更容易找到合适的人选 坚持解决问题 材料维护。
• 精确列表 所做的更改可以快速生成 而且容易，使它更容易 告知用户有关的信息 它是如何从版本更改为 版本
• 很容易'回滚' 早期版本的 信息，如果是一个严重的错误 在改变期间做出来。

源代码管理就像保险！你希望你永远不需要它，但很高兴你拥有它！

Answer 16

我真的很抱歉，但如果你真的不得不在开发环境中争论[源代码控制的正式化]，那么你处于绝望的境地。如果您的老板确实需要确信源代码控制是值得的，那么您的老板根本不适合成为一组软件开发人员的经理。为了让某人有效地管理，他们至少需要对景观有一个基本的了解。我甚至无法想象当你真的需要争论一些值得讨论并做一个演示的东西时会发生什么。

没有源头控制的开发就像驾驶汽车一样没有休息。你失去了进行无缝并发开发的能力，你丢失了代码在工作副本中备份，你失去了通过代码注释进行历史研究的能力，你失去了看到伴随离散变化的上下文和评论的好处，你只是失去，期间。使用源代码控制是如此明显并且有很多好处，令人震惊的是你必须证明它是合理的。

在工作中，我们使用subversion，但是一些开发人员（包括我自己）通过git-svn桥在本地使用Git。对于个人工作，我使用Git。

Answer 17

为什么您的团队不应采用源代码管理？

即使是独立开发者，我也使用源代码控制。在现代软件开发环境中，我可以想到为什么你不使用源代码控制的原因很少。更令人惊讶的是，你还没有它。这个问题让我觉得像房屋画家那样问“我们为什么要采用梯子。你知道，梯子不会把房子涂成漆 - 刷子就行了。”

Answer 18

坚持底线，解释它与金钱的关系，你的老板可能会倾听。

如果你只是一个程序员，我会说主要的争论是你浪费时间（因此钱）修复简单的错误，试图回滚那些被认为是错误想法的代码等等。

如果您不止一个程序员，那么上面两次加上它是唯一能够在相同代码库上一起工作而又不会浪费更多时间等待彼此的理智方式，

Visual Source安全比没有好，但有几乎在每个方面都更好的免费选项。如果你的老板需要一个演示来理解为什么源控制是必不可少的，他可能不关心你开悟后使用什么工具。你有其他工具的经验，而不是vss再次涉及底线，这可能就足够了。

Answer 19

为什么要正式演示？

假设团队规模至少为2，请做一个真实的例子：让两个（或更多，越多越好）的人获得代码，进行更改并显示使用任何内容集成所有这些更改所需的内容非源代码控制意味着您使用。

然后使用源代码控制执行相同的方案。

使用源代码控制节省的时间和痛苦不言自明。

Answer 20

由于：

1. 它将降低成本 - 开发人员必须花费更少的时间来检查真实VCS中的项目，而不是当前的临时方法。

2. 它将保护组织的知识产权 - 这应该是任何软件公司（数据除外）最重要的考虑因素。您需要付费才能创建软件 - 不应该完整地访问它吗？

3. 它将提供更快，更可靠和更直接的备份机制 - 所有VCS都具有内置的转储功能。这些往往比简单的文件副本更成熟。

4. 它将作为开发人员之间的通信机制 - 根据版本控制系统，您可以使用注释/标签/结帐状态来确定是否有其他人处理过文件，如果它已被提升为生产，如果它有相应的支持票号等。

5. 它简化了开发 - 比较文件版本以及其他机制的能力将有利于您的公司时期。

Answer 21

我们使用版本控制的主要原因是一致性。

如果项目不一致，那么问题就会发生，代码就会丢失。

Answer 22

确保您已为团队的其他成员购买。也许你可以测试你的演示文稿？希望他们也能看到这种需求。

很高兴看到自下而上的良好做法。也许每个人都更有可能采用这种做法，如果它来自他们自己的一个而不是一些管理职责。

Answer 23

避免像

这样的事情

     "Hey! What happens ? It worked yesterday."

Answer 24

说服管理层在SCCS上投入时间的最简单方法是关注备份和存档。通过使用Subversion（SVN）之类的东西，您可以立即将任何项目恢复到任何时间点。没有必要让人查看备份磁带或担心在一个钝的目录结构中跟踪多个版本。

显然还有许多其他优点（即2个人同时在同一个文件上工作），但备份是很多年前我公司迅速销售的。

Answer 25

其他人已经提到了其他地方的源控制的具体好处，但我想明确地解决问题的“VSS”部分。

如果您的老板想要使用Microsoft工具，Team Foundation Server与Team Suite是一个非常好的组合。它还包含其他工具，例如错误跟踪，文档和报告功能，这是一个很好的平台，可以在以后改进您的流程。我工作的地方很开心，我的同事告诉我关于VSS的恐怖故事。

将TFS作为对“Microsoft工具”问题的回应而牢记。