对于一家小公司（15个开发人员）来说，不使用托管的源代码/版本控制是否很不寻常？[关闭]

这并不是一个真正的技术问题，但是这里还有一些其他有关源代码控制和最佳实践的问题。

我工作的公司（将保持匿名）使用网络共享来托管其源代码和发布的代码。开发人员或管理人员的责任是根据源代码是否已发布以及版本和内容将其手动移动到正确的文件夹中。我们围绕着记录文件名和版本以及更改内容的地方散布着各种电子表格，并且一些团队还在每个文件的顶部放置了不同版本的详细信息。每个团队（2-3个团队）在公司内部的做法似乎有所不同。可以想象，这是一个有组织的混乱-有组织，因为“正确的人”知道他们的东西在哪里，但是却一团糟，因为它们完全不同，并且依赖于人们随时记住要做的事情。

一段时间以来，我一直在努力寻求某种托管源代码控制，但在公司内部似乎无法获得足够的支持。我的主要论据是：

• 我们目前很脆弱；在任何时候，任何人都可能忘记执行我们必须执行的许多发布操作之一，这可能意味着未正确存储整个版本。如有必要，可能需要数小时甚至数天的时间才能将版本拼凑在一起
• 我们正在开发新功能以及错误修复，并且由于某些工作尚未完成，因此常常不得不延迟发布其中一个。我们还必须强迫客户采用包含新功能的版本，即使他们只想修复错误也是如此，因为我们实际上只在开发一个版本。
• 我们遇到了Visual Studio问题，因为多个开发人员正在同时使用相同的项目（不是相同的文件，但是仍然会引起问题）
• 只有15个开发人员，但我们的工作方式有所不同。我们都必须遵循一种标准的全公司范围的方法，这会更好吗？

我的问题是：

1. 如此规模的小组没有源代码管理是正常的吗？
2. 到目前为止，我仅获得了没有源代码控制的模糊原因- 考虑到上述信息，您认为哪些原因对于不实施源代码控制可能是有效的？
3. 我可以将更多的源代码控制理由添加到我的武器库中吗？

我主要是想了解为什么我受到如此多的抵制，所以请诚实地回答。

我将给我相信采用最平衡方法并回答了所有三个问题的人的答案。

提前致谢

1. 它可能不是正常的，但是作为TREB 说，它可能不是寻常

2. 就像其他人所说的那样，没有正当理由在您这样大小的公司中没有源代码控制。因此，您需要找出并解决无效原因：

   a）最主要的是现状：“如果没有损坏，请不要修复”。这很困难：您可以开始指出所有无法正常工作的事物（这可以迅速将您标记为“消极人”），或者您只是在等待某些事情破裂（可能永远不会发生）。发生），或者您可以强调所有可能出错的地方。不幸的是负责人的小公司相对不受“事情可能出错”，直到他们实际上做去错了...

   b）无知/恐惧/不确定性：“我们真的不了解什么是源代码控制；我们不知道如何使用它；我们不知道该选择哪种工具；这将束缚我们的风格”。这是我绝对不会将它们发送到这里的原因之一！对于您自己来说，这可能是一个非常艰巨的任务，但是我认为，为了最大程度地提高您的机会，您需要提供一个“交钥匙”解决方案，而不需要太多的变体或替代品。您需要一个清晰的主意：如何适应/改变工作流程以使用给定的工具；如何/是否计划向后移植现有代码；您认为可以以多快的速度“培训”用户并使他们运行？如何管理过渡期（如果有的话）；可能“花费”多少钱（以小时为单位，如果不是以美元为单位）。

   c）可能还有其他原因（例如，以前使用VSS的不良经历，或者已经阅读过有关所谓的过于复杂的工具的“恐怖故事”），但是当发现它们时，您必须逐一打击它们。

3. 其他答案中概述了进行源代码控制的充分理由。我的建议是挑选出主要的2或3，可能真的能够为贵公司的差异，打磨，并在会议中许多同事尽可能的呈现出来。尝试引起讨论：即使您不立即说服他们，您也将深入了解症结所在。

（您是否已阅读/听说过“更改功能”？）

在没有源代码控制的情况下工作的人数绝对是不正常的-在没有源代码控制的情况下可以有效工作的最大程序员群的大小小于或等于一个。对于任何规模的专业团队来说，如果都没有版本控制，这是绝对不可原谅的，也许我没有创造力，但是我无法提出您为什么要放弃它的任何理由。

版本控制只是另一种工具-一种功能特别强大的工具，相对于其最低的成本，它可以带来巨大的好处。它使您能够以有组织的方式，通过分支，自动合并，标记等各种其他方便的事情来精细地管理所有更改。如果您需要从多个版本中构建一个版本，则可以从该时间点签出代码，而无需跳过任何其他步骤即可进行构建。

更重要的是，如果您需要编写错误修正，则可以将其合并到更新中，而不必交付正在使用的新功能-因为它们在另一个分支上，并且在开发的其余部分需要担心，它们还不存在。

您遇到阻力是因为您在挑战公司的文化。无论您说什么，他们都需要时间进行调整。您能做的最好的事情就是继续努力，如果公司真的不让步，那就另谋一份更适合您作为开发人员水平的工作。

如此规模的小组没有源代码管理是正常的吗？

以我的经验，这不是规范，但并不像这里的其他答案所建议的那样完全不寻常。大多数小型公司的确使用源代码控制，但是不幸的是，很多公司没有使用源代码控制。

到目前为止，我仅获得了没有源代码控制的模糊原因-考虑到上述信息，您认为哪些原因对于不实施源代码控制可能是有效的？

有关SO的良好讨论，请参见此问题。公认的答案是：
“没有充分的理由不使用版本控制。不是一个。”

我可以将更多的源代码控制理由添加到我的武器库中吗？

我遇到的所有开发人员和项目经理之间的共识是，当然，在程序员和SO上的共识是必须进行源代码控制。这是公认的最佳实践。如果有人决定忽略它，那么他需要提出一些非常有力且令人信服的论据，为什么这对他来说是正确的决定（即比“我们从不需要它，所以为什么将来需要它”更多）。到目前为止，您提出的论点都集中在特定问题上，也许您应该按照“每个人都这样做”的方式尝试更广泛的方法，那么为什么我们也不这样做呢？

源代码控制甚至对一个开发人员团队都是有利的。任何源代码控制系统基本上都是一个版本控制系统，可以跟踪更改。想象一个开发人员，他可能已经删除了一些代码，并认为现在需要该代码。他可以找回旧代码吗？

只是去寻找可以帮助您的工具。大小并不重要。质量无处不在。

听起来您已经在使用版本控制系统，但不是一个很好的系统。人们似乎已经认识到需要版本控制。您只需要将它们介绍到下一个层次-软件版本控制。

如果是我，我将介绍SCM作为他们已经在做的事情的改进版本。我要强调的是，使用好的工具如何使许多已经在进行的工作自动化。

• SCM系统不仅记录更改内容，而且记录更改内容以及原因，而不是在电子表格中记录更改。

• 作为奖励，您可以返回到代码生命中的任何时候，然后查看实际存在的内容。

• 不必在不同的文件夹中使用不同版本的代码，而无需在文件夹之间移动/合并内容以移植更改，您可以将所有内容保留在同一位置，并且（更重要的是）让该工具进行合并。

正如其他人已经说过的那样，我会遇到一些阻力，因此我将在正在做的事情上使用它来制作系统原型。

（顺便说一句，我实际上将我的简历和其他文档放在SVN下。然后，我又多次担任配置和集成管理器的角色。）

到目前为止，我仅获得了没有源代码控制的模糊原因- 考虑到上述信息，您认为哪些原因对于不实施源代码控制可能是有效的？

• 您正在开发的产品是版本控制系统；经理们担心防止现有产品影响新产品的设计和实施。

• 在BASE的周末和公牛奔跑之间，那些寻求刺激的经理喜欢开车上班，想知道是否一切都还没结束。

• 避免敌意收购。谁想要获得以这种方式管理的软件开发团队？

我可以将更多的源代码控制理由添加到我的武器库中吗？

• 您已经在进行版本控制，但是目前您正在以可想象的效率最低，最费力，最容易出错的方式进行版本控制。使用VCS将节省资金，节省时间并提高质量。

• 节省磁盘空间。大多数版本控制系统仅保存文件之间的增量。当前，您正在保存每个文件的每个版本的完整副本。（备份所有这些副本必须花费大量时间和空间！）

• 几个开发人员可以同时处理同一个文件，并且可以在没有太大麻烦的情况下协调差异。在没有VCS的情况下，合并更改当然是可能的，但是在这种情况下，几乎不可能跟踪谁更改了内容，更改的时间和原因。

• 使开发人员知道可以随时恢复任何版本，因此可以自由尝试新的想法。

• 更好的流程可以更轻松地雇用和留住有才华的开发人员。

如此规模的小组没有源代码管理是正常的吗？

绝对不是。当我在目前的公司工作时，只有一个人您应该将更改后的代码发送给他，然后他将其合并。我可以在几天之内说服所有人使用SVN。

到目前为止，我仅获得了没有源代码控制的模糊原因-考虑到上述信息，您认为哪些原因对于不实施源代码控制可能是有效的？

我认为您只听到模糊的原因是因为没有使用版本控制的正当理由。

我可以将更多的源代码控制理由添加到我的武器库中吗？

是的，原因有很多。

1. 分支使您可以开发新功能而不会干扰其他开发。
2. 每次提交都会为您提供有关确切更改内容，更改对象以及更改时间的信息。
3. 您可以轻松地提交错误修正，然后将其部署给客户，而忽略未完成的新功能。
4. 如果客户害怕使用较新的版本，则可以维护不同的版本。
5. 您可以轻松地处理相同的项目（甚至相同的源文件！）。
6. 您可以轻松地恢复错误，并在发生该错误之后保留更改。

有些人很难意识到现状是多么糟糕，直到他们看到对自己更好的东西为止。您需要的是一个很好的演示。展示一些可以改进的实际任务示例。“这花了我4个小时来跟踪当前的系统，但是这个源代码控制命令立即告诉了我。”

不使用源代码控制会提出问题，即使是对于单独的开发人员也是如此。您可以毫不费力地编辑而不会冒任何损失的简单事实，弥补了数周或数天的学习努力。

就是说，如果您不能说服经理引入源代码控制，请帮自己一个忙，至少在本地使用git或mercurial之类的东西-如果由于缺乏源代码控制而使事情破裂，至少您不会一个谁做的。

我公司使用GIT进行版本控制。该公司是一名开发人员，一名首席执行官，一名保安人员，一名清洁女工和一名接待员。他们都是我。每次都必须进行源代码版本控制。

我自己一个人从事许多项目，但我仍然使用版本控制。大小无所谓。拥有版本控制总是有帮助的。

有理由在Joel测试中排名第一：http : //www.joelonsoftware.com/articles/fog0000000043.html

同样，它使列表中的＃2和＃3成为可能。

几年前，我们在一个由6人组成的团队中担任类似职务。其中一名开发人员采取了在共享文件夹所在的开发服务器上安装SVN的步骤，并开始使用它。

每个人都紧随其后，不久之后我们实施了CI（CruiseControl），并对我们的构建和发布流程进行了革命性的改进，以包括自动化和质量检查。

WTF ？！这可能是我见过的最荒谬的问题。您需要找到新工作。15位开发人员？您认为这是一个小团队？疯了吧。经理应立即终止。老实说，阅读完这个问题后，我将做噩梦。请告诉我们您出售的产品，所以我们都知道不买！我不知道这是什么吓人的问题，或者说这并不稀奇的答案！

我无法想象15个开发人员如何在没有任何源代码控制的情况下可以工作。但是，来自：

（...）使用网络共享托管其源代码（...）

我假设您已经创建了自己的穷人版控件，例如VSS（也基于共享文件夹）。这是冒险的，效率不高。

向您的老板说明情况有多严重，投资一些为期2天的SVN或GIT培训，并在您的代码仍处于合理状态的同时开始使用实际版本控制系统。

如果我一天不做几次，或者至少在离开家之前，我觉得..有些东西丢失了，有些错误了。

1998年，我曾经在一家只有2个开发人员（我+长发的管理人员）的公司工作。真方便。

在我的职业生涯中，有几次我失去了一天的工作，因为我做了类似mv的工作，而不是cp和rm -rf。让我哭泣，在绝望中在城市的街道上四处游荡。

在进入SE的13年中，我在5家公司工作，参加过一些会议，从未遇到没有使用版本控制的公司。

但是，我最喜欢的室内设计公司只有20名员工，使用白板进行项目管理和协作。他们知道其明显的错误，但似乎没有时间升级。它以某种方式起作用。不要问我如何。

成为领导者。成为领导者意味着做正确的事；主动解决问题。领导没有做任何事情，因为没有足够的共识。优秀的领导者会学会识别应该建立共识和何时达成共识的情况。显然，这是在做事。缺乏代码控制功能迟早会在​​您的面前大怒。

领导者通常不担任官方管理职务。人们会跟随好而果断的领导者，无论头衔如何。

如果您的决定性努力受到挫败，特别是如果来自管理层，那么这是您摆脱困境的明确标志。这会拖累您的专业发展；和有能力的开发人员和无能的管理人员不能混为一谈，无能的人将使您陷入困境。

好，闪回正传给我。签收。祝好运。

1. 拿秒表，
   • 计算您在电子表格中花费的仅用于同步版本的时间
   • 计算您修复损坏版本所花费的时间
   • 计算人们在走廊上大喊的次数：“ 我正在编辑main.c !，只是为了确保现在没有其他人！” 。
   • 计算因客户的错误修正包含其他更改而从客户那里收到的投诉数量
   • 仅仅因为您无法同步版本来计算发布的延迟时间
2. 使用此数据制作PowerPoint，并与vcs的工作方式进行比较。
3. 演出管理

这只是一场等待发生的事故。您没有代码历史记录，一口气，您的一名开发人员就可以消除数月的工作。作为一家小公司，您无法承受这种挫折。

在共享驱动器上，您也很有机会。即使备份良好，您还能承受多长时间不工作。1小时1天1周。重新安装新服务器，从备份中还原等需要花费多长时间。同样，作为一家小型公司，您可能没有备用的备用硬件，并且可能无法轻易花钱来加快运输速度等。

还要考虑异地存储。洪水或大火并不是那么罕见。如果数小时后建筑物着火，将会发生什么情况。将会失去多少个月的工作。像github这样的托管代码存储库将对此非常有价值。即使在托管服务上使用简单的SVN服务器也将在这一领域迈出更大的一步。

LordScree，我和您的处境几乎一样，我的直属团队大约有15个开发人员。我难以置信（几乎感到恐惧）未使用源代码控制。我最初对“我们应该使用源代码控制”的回答是“我们没有时间实施”。对我来说，就像穿着内衣一样，源代码管理不是可选的。几个月后，我也获得了实施TFS的批准，该组织选择了TFS，因为它是MS，并且具有90天的试用期。最重要的是，当他们一直在努力摆脱源代码控制时，很难说服组织对源代码控制的需求。我告诉开发人员，只要您发现自己备份文件（尤其是备份的文件名或目录中带有日期），便是将某些内容放入源代码管理的示例。我不 对于您来说，没有什么绝妙的答案，但是我确实认为这很罕见。我正在同一个战斗中，将使您了解进度。而且，希望我能在其他地方找到进步，因为我不能混乱！

我们有3名开发人员，并使用源代码控制。在我的个人项目中，我只有一名开发人员，并且使用源代码控制。它不仅对团队管理有用，而且对能够进行实验工作而不必担心您要破坏某些东西很有用。

说服管理的最简单方法？整个产品的风险较小，从长远来看，它将提高开发人员的生产率。两者都是正确的，而且都吸引管理者。

这绝不是正常的情况，我认为您应该为在您的公司中获得此设置付出艰苦的努力。它具有深远的益处，并在当你接近末日实现相同的，点它不是归入情况如果不破不解决它

不执行它的任何原因都可能只是做不好的借口或等待发生错误的借口。

只需告诉他们今年1月1日找到应用程序的功能有多大

怎么样哎三月加入这个功能，我认为我们需要扩大多一点这一点。

哇，此错误154256已在此提交中修复。

我可以分支出该应用程序，并发送部署没有问题的人，你可以继续工作。

这可以持续下去...（请记住，稍后再对提交添加注释，否则将作为另一个问题出现）

我在一个人的项目和工作项目中使用版本控制，在这里，我们多达30至40个人同时处理同一代码。版本控制具有组织上的优势，但是还原文件和隐藏更改的能力确实可以消除管理代码的麻烦……最后，这对于程序员来说是最佳方案，因此他们可以只专注于编码。

支持不使用版本控制的原因非常有限。我能想到的只是事物的技术方面。

• 太多的学习过程无法转换整个员工的工作流程以合并版本控制系统，从而提高了成本效益。
• 您的项目经理认为将开销引入管理和维护存储库的工作流程中并没有好处。（主要是旧版本控制系统存在的问题）

使用版本控制系统的原因很多。至少不要移动任何东西。使用补丁。版本控制系统可以完全按照您说的去做。

• 您可以在进行错误修复的同时使用下一版本，并分别发布它们。
• 无需将文件从一个位置移动到另一个位置上，而是可以创建一个分支，并在完成后将其合并到主文件夹中。
• 每个开发人员可以拥有自己的源代码副本，以防止在多台计算机上打开同一项目时出现问题。
• 意外发生，如果代码被严重破坏，则只需回滚到上一个有效的修订版本号即可。
• 版本控制与错误跟踪器和持续集成系统完美搭配使用。

作为一个人的团队，我个人使用版本控制，错误跟踪，持续集成，代码审查，代码一致性检查，单元测试，硒测试，源代码分析，而且我可能会忘记更多。我承认，学习曲线有些许变化。对于自动化的其他步骤，还需要权衡额外的管理时间。以我的经验，节省的精力超过了额外的管理时间。

在1990年的第一份严肃的工作中，我是我部门中唯一的开发人员，并且不知道使用源代码控制。

此后不久，我了解到，从那时起，我再也没有见过一个项目没有使其成为他们最初建立的项目之一。

由于删除了错误级别的文件夹，我几乎失去了该工作的所有工作。幸运的是，我在一周前将副本放在5英寸的软盘上，并且能够在几天之内重新创建一周的工作。

因此，我想如果这是团队中每个人的第一个项目并且没人知道的话，我认为这是可以接受的，但是，即使有一个人可以真正解释其好处，而团队仍然不听，我会重新分类小组从“幼稚”到“危险地无能”的观点（拒绝使用具有如此广泛证明的好处的工具几乎是犯罪行为-就像您的团队不信任“编译器”并坚持以汇编语言来完成所有工作一样）。

我在很多从事嵌入式软件/硬件开发的小型工程/电子公司中进行了很多工作。

在这些地方，SCM并不是电子工程文化的一部分。他们通常每个项目只有一名工程师，他们只需要备份最新版本。

因此，分支/合并甚至共享代码被认为是无关紧要的。而且，这些公司可能是ISO9000，因此，虽然很奇怪，但该过程可能已记录在案。

无论如何，我/其他开发人员只是个人开始使用SCM。

在我工作的地方，我们有同样的问题。我目前正在尝试在“雷达之下”滑动源代码控制，以解决您遇到的相同问题。我将化石用于自己开发的项目。

我最近在公司LAN上安装了化石服务器，因此现在更加方便。我希望，当我在一些较小的项目中证明其有用性时，我会破坏抵抗力并使我们摆脱网络文件夹的现状。

我听说不使用化石或其他一些VCS的最大原因是：

1. 许多“程序员”都是脚本小子，不知道如何使用它
2. 那些可以学习的人认为使用它很麻烦
3. 这些人是守旧的人，对网络文件夹比较满意，所以每个人都应该
4. 没有人有时间进行正确设置或学习如何使用它
5. 虽然功能可能很棒，但都不是必需的

如您所见，我试图通过证明它易于使用，已经设置，易于学习并且功能完全值得来解决这些问题。

最后，即使您不让他们使用源代码管理，也都在网络树中。Fossil可以对整个树中的所有内容进行版本控制，您可以将其设置为在发生文件更改时（至少每小时）运行一次。我已经完成了一些我们“不需要源代码控制”的项目，最终当出现问题时我可以将其回滚到一个好的版本。

正确地做，他们甚至都不知道您已经完成了。然后，您可以成为英雄，还原损坏的构建，并演示您的工具多么有用。

既然已经有了Git和Mercurial之类的DVCS工具，并且安装和使用起来非常简单，那么即使是1（！）的团队也不使用源代码控制，也确实没有任何借口。这与团队规模无关，而是与您的更改历史记录有关，以及支持工作流的能力，例如在处理新版本时修复生产问题，以及跟踪不同版本的源代码状态。

如果为我提供的团队规模达到了这样的规模，并且没有一个开发人员建议使用VCS，或者如果“管理”阻止了他们，那么我会拒绝它。如今，这不是一种可接受的工作方式。

您应该立即获得GIT版本控制。您甚至可以在Google Code Project Hosting中使用它。当其他人看到您在手动复制内容时，只需单击一下即可提交更改，那么他们可能会改变主意。

哇，哇 虽然我认为这不是处理代码控制的最佳方法，但我在一家拥有6个开发人员且未使用源代码控制的公司工作并不罕见，他们有自己的内部文件管理方式，发行经理和什么都不会监督所有变化。实际上，口头禅是只要在功能周围进行某种转换，就可以将新功能添加到项目中。

例如，我们正在使用PHP编写的AB级社交网络，客户端希望该功能能够订阅用户个人资料。基本上，将功能包装在这样的检查中：if（ENABLE_SUBSCRIBE_FUNCTIONALITY == true）{然后执行代码}

在一个特定的文件上，我所工作过的地方从来没有一次有一个以上的开发人员，大多数东西都是模块化的，因此在这种情况下就不需要源代码控制了。但是，我相信在大多数情况下，源代码控制的优点远胜于没有源代码控制的缺点。

事实是，您的公司诉诸于电子表格来记录文件更改，而当Git或Subversion这样的功能可以为您处理这些更改时，所做的更改绝对是荒谬的。

似乎您已经说服了，但是组织中的某人没有授权您执行此操作。正如您从其他评论中看到的那样，您应该这样做。

您可以在此处找到一些信息：http : //www.internetcontact.be/scm/?page_id=358

最重要的因素是，您的客户被迫进入最后一个“不稳定”的分支，并且如果您与客户的合同使您有责任部署不稳定的版本，则您的公司正在亏损。您应该在这里真正关注发布稳定性。这是进行源代码管理的主要原因，而且似乎是您的主要失败。由于您已经拥有替代系统，因此通过使用源代码控制不会对其他系统进行太多改进。