这不是一个真正的技术问题，但是这里还有一些其他有关源代码控制和最佳实践的问题。
我工作的公司（将保持匿名）使用网络共享来托管其源代码和已发布的代码。开发人员或管理人员的责任是根据源代码是否已发布以及版本和内容手动将其移动到正确的文件夹中。我们围绕着记录文件名和版本以及更改内容的地方散布着各种电子表格，一些团队还在每个文件的顶部放置了不同版本的详细信息。每个团队（2-3个团队）在公司内部的做法似乎有所不同。可以想象，这是一个有组织的混乱-有组织，因为“正确的人”知道他们的东西在哪里，但是却一团糟，因为它们完全不同，并且依赖于人们随时记住要做的事情。一件好事是，所有内容都会每晚进行备份并无限期保存，因此，如果出错，可以恢复快照。有一阵子，但我似乎无法在公司内部获得足够的支持。我的主要论据是：
我们目前脆弱。在任何时候，任何人都可能忘记执行
我们必须执行的许多释放操作之一，这可能意味着整个版本未正确存储。
可能需要几个小时甚至几天的时间来将版本重新组合在一起
我们正在开发新功能以及错误修复，并且常常不得不延迟发布其中一个的另一个版本因为某些工作尚未完成。我们还必须迫使
客户采用包含新功能的版本，即使他们只是想进行错误修复，
因为我们实际上只在开发一个版本，所以我们遇到了Visual Studio出现问题，因为多个
开发人员正在同时使用相同的项目（不是相同的文件，但仍然会引起问题）。
只有15个开发人员，但是我们的工作方式有所不同；
最好有一种我们都必须遵循的公司范围内的标准方法？
我的问题是：
这个规模的小组没有源代码控制是正常的吗？
到目前为止，我只得到模糊的原因而没有源代码控制-您建议的原因有哪些？
鉴于上述信息，要实施源代码控制吗？
我还可以在我的武器库中添加源代码控制的其他原因吗？要了解为什么我会受到如此强烈的抵制，请诚实地回答。
我将回答我相信采取了最平衡方法并回答了所有三个问题的人。
预先感谢
#1 楼
这可能不正常，但正如Treb所说，这可能并不罕见。
正如其他人所说，没有合理的理由不对公司进行源代码控制您的尺码。因此，您需要找出并消除无效原因：
a）主要的原因是现状：“如果没有破裂，请不要修复它”。这很困难：您可以开始指出所有无法正常工作的事物（这可以迅速将您标记为“消极人”），或者您只是在等待某些事情破裂（可能永远不会发生）。发生），或者您可以强调所有可能出错的地方。不幸的是，负责小公司的人相对不会渗透到“可能出错的地方”，直到他们确实出错了。什么是源代码控制；我们不知道如何使用它；我们不知道选择哪种工具；它将限制我们的样式”。这是我绝对不会将它们发送到这里的原因之一！对于您自己来说，这可能是一个非常艰巨的任务，但是我认为，为了最大程度地提高您的机会，您需要提供一个“交钥匙”解决方案，而无需太多变型或替代方案。您需要有一个清晰的主意：如何适应/转换工作流程以使用给定的工具；如何/是否计划向后移植现有代码；您认为可以以多快的速度“培训”用户并使他们运行？如何管理过渡期（如果有的话）；
c）可能有其他原因（例如，以前使用VSS的不良经历，或者已经读过“恐怖故事”）（“小时”，如果不是美元）。关于据称过于复杂的工具），但是当您发现它们时，必须将它们单独击杀。
其他答案中概述了进行源代码控制的充分理由。我的建议是挑选出可能对您的公司产生重大影响的主要2项或3项，并加以完善，并在一次会议上向尽可能多的同事介绍。尝试引起讨论：即使您不立即说服他们，您也将深入了解症结所在。
（您是否已阅读/听说过“变更功能”？） >
评论
感谢您对正常与异常之间的（非常）必要的区分。 +1
–keppla
2011年10月4日12:58
+1表示无知/困惑。如果您是专业软件开发人员，没有使用SCM，那么您就不是。期。
–克里斯·桑顿
2011年10月4日在20:09
出于好奇，当有无数的免费应用程序时，谁愿意为每人支付300美元的源代码管理费用（Valut，根据您的Wiki链接）？
–抢夺
2011年10月4日在22:17
关于第2点：对于任何规模的团队（包括1人组成的团队），我都没有看到任何不使用源代码控制的正当理由...？
–詹姆斯·科里（James Khoury）
2011年10月4日23:49
一些小组没有版本控制的另一个原因-设置过程涉及一些开销和学习。您需要一台服务器来托管代码库。您需要管理服务器和该服务器上的VC软件。您需要备份VC数据库，创建和测试恢复计划并监视备份，以确保备份/恢复仍然有效。所有这些管理需要时间。在软件管理不善的组织中，开发人员花费在管理VC系统上的时间可能会受到惩罚而不是得到回报。
–杰伊·埃尔斯顿（Jay Elston）
2011年10月5日在18:30
#2 楼
在没有源代码控制的情况下工作的人数绝对是不正常的，在没有源代码控制的情况下可以有效工作的最大程序员群的大小小于或等于一个。没有版本控制对于任何规模的专业团队来说都是绝对不可原谅的，也许我没有创造力，但是我无法提出您为什么要放弃它的任何理由。版本控制只是另一种工具-一种功能特别强大的工具，相对于其最低的成本，它可以带来巨大的好处。它使您能够以有组织的方式，通过分支，自动合并，标记等所有其他方便的事情来精细地管理所有更改。如果您需要从多个版本中构建一个版本，则可以从该时间点签出代码，并且无需跳过任何其他步骤就可以构建。编写一个错误修正，您可以将其合并到更新中，而不必交付正在使用的新功能，因为它们在另一个分支上，并且就其他方面而言，它们无需考虑已经存在。
您正在遇到阻力，因为您正在挑战公司的文化。无论您说什么，他们都需要时间进行调整。您可以做的最好的事情就是继续努力，如果公司真的不让步，那就找到另一个更适合您作为开发人员水平的工作。
评论
不幸的是，不可原谅并不等于异常。
– Marjan Venema
2011年10月4日上午10:11
更不用说有免费的源代码控制提供程序，因此这并不是一个昂贵的行动。
– Mantorok
2011年10月4日13:50
就使人们改变其习惯，工作流程和程序而言，这可能是昂贵的。
–user1936
2011年10月4日15:39
@Rook：绝对。但是，我宁愿拥有不需要的安全网，也不愿拥有我不需要的安全网。在我不知道什么是版本控制系统之前，我就已经在编程。虽然没有必要，但是剥夺自己的好工具是愚蠢的。
–琼·普迪（Jon Purdy）
2011年10月4日17:21
即使我是唯一的开发人员，我也无法想象没有源代码控制的情况下进行开发。
– webbiedave
2011年10月4日17:40
#3 楼
这种规模的小组没有源代码控制是正常的吗？
以我的经验，这不是规范，但并不像这里的其他答案那样完全不寻常建议。大多数小公司确实使用了源代码控制，但不幸的是，有很多公司没有使用。
还有其他我可以添加到武器库中的源代码控制理由吗？ br />
我遇到的所有开发人员和项目经理之间的共识，当然，在程序员和SO上的共识是必须进行源代码控制。这是公认的最佳做法。如果有人决定忽略它，那么他需要提出一些非常有力和令人信服的论据，为什么这对他来说是正确的决定（即比“我们从不需要它，所以为什么将来需要它”更多）。到目前为止，您提出的论点都集中在特定问题上，也许您应该尝试按照“每个人都这样做的方法”尝试更广泛的方法，那么为什么我们也不这样做？
评论
“不是很多”……嗯……在同一代码库上有15个开发人员？我在哪里，我们在...的时候添加了SCC ... 5 + 2个开发人员都在同一代码库上，所以我们觉得是时候了。我肯定希望在同一代码库上15个开发人员且没有SCC非常不寻常:-)
–马丁·巴（Martin Ba）
2011年10月4日，12：01
@马丁：找到15个所有人都患有“这里未发明的综合征”并没有什么不寻常...我想也许所有小型公司（少于20名员工）中有5％没有源头控制。希望您的经历与我不同；-)
–特雷布
2011年10月4日12:57
不幸的是，+ 1并不罕见。
–乔纳斯（Jonas）
2011年10月4日13:46
+1代表不寻常。有些人只是不了解源代码控制的好处胜过成本。他们担心成本，并通过将文件或补丁复制到“构建”的“中央”合并工作区中进行集成；主要是因为他们认为这是行得通的，并且没有人在开发环境中进行投资。通常，这是由于人们认为他们在代码上要做很多工作，因此他们不会在环境上浪费开发时间。我发现，在更高效的环境中节省的时间比回报开发者所付出的投资多
–埃德温·巴克
2011年10月4日15:54
#4 楼
源代码控制甚至对一个开发人员团队都是有利的。任何源代码控制系统基本上都是一个版本控制系统，可以跟踪更改。想象一个开发人员，他可能已经删除了一些代码，并认为现在需要该代码。他可以找回旧代码吗？只需要一种可以帮助您的工具。大小并不重要。质量无处不在。
评论
+1，我目前是一个开发团队，并且使用源代码管理。我什至在家中使用源代码管理来管理与软件开发无关的个人文档，例如烹饪食谱和简历。
– Maple_shaft♦
2011年10月4日上午11:37
+1，许多小商店开始使用zip文件作为存档。思考“我可能想回到这一点，所以我将整个过程压缩”。不一样，一点也不。一旦您熟悉了SCM以及构建在顶部的优秀工具（log，diff，blame等），您将永远不会回头。
–克里斯·桑顿
2011年10月4日20:07
SCM的另一个重要用途：我星期一来，想知道上周五我到底在干什么。我只是做一个比较或查看最后一个签入日志，然后我立即回到该区域。
–克里斯·桑顿
2011年10月4日在20:08
想象一个开发人员，他可能已经删除了一些代码，并认为现在需要该代码。他可以找回旧代码吗？是的，我只使用了几周前进行的最后一次备份，每当我要进行重大更改时，我都会进行备份。几年来没有让我失败，也不需要（或觉得我应该使用）源代码控制...
–user541686
2011-10-5 2:51
我是唯一在我们公司从事开发工作的人（我也从事IT工作），当我起步时，我没有使用源代码控制，从来没有发生过灾难，但是我最终意识到了自己的处境。稍后，我自己安装了Mercuarial，之前并没有使用过它，也没有在Windows ui上使用过它，它已经成为了很大的帮助。
–托尼·彼得森（Tony Peterson）
2011年10月5日10:39
#5 楼
听起来您已经在使用版本控制系统，但不是一个很好的系统。人们似乎已经认识到需要版本控制。您只需要将它们介绍到更高的层次-软件版本控制。如果是我，我将介绍SCM作为他们已经在做的改进版本。我要强调的是，使用好的工具如何使许多已经在进行的工作实现自动化。
SCM系统不会在电子表格中记录更改，而是保持
跟踪不仅是更改的内容，还包括更改的内容以及更改的原因。
不必使用不同版本的代码在不同的文件夹中，并且需要在文件夹之间移动/合并内容以移植更改，您可以将所有内容保存在同一位置，（更重要的是）让该工具进行合并。
已经说过了，我会遇到一些阻力，所以我会在正在做的事情上使用它来对系统进行原型设计。我已经多次担任配置和集成管理器的角色。）
#6 楼
到目前为止，我仅获得了没有源代码控制的模糊原因
-考虑到上述信息，您认为什么原因可能会导致不执行源代码控制有效？
您正在开发的产品是版本控制系统；经理担心防止现有产品影响新产品的设计和实施。
在BASE的周末和公牛奔跑的周末之间，那些寻求刺激的经理喜欢开车上班，想知道一切是否都死了。 />避免敌意收购。谁想获得以这种方式管理的软件开发团队？
您已经在进行版本控制，但是目前您正在以可想象的效率最低，最费力，最容易出错的方式进行版本控制。使用VCS将节省资金，节省时间并提高质量。
节省磁盘空间。大多数版本控制系统仅保存文件之间的增量。当前，您正在保存每个文件的每个版本的完整副本。 （备份所有这些副本必须花费大量的时间和空间！）
几个开发人员可以同时处理同一个文件，并且无需花费太多时间即可调和差异。在没有VCS的情况下，合并更改当然是可能的，但是在这种情况下，几乎不可能跟踪谁更改了内容，更改的时间和原因。时间。
更好的流程使雇用和留住才华横溢的开发人员更加容易。
评论
在第二点，许多VCS保存增量，但是Git为文件的每个唯一哈希保存整个文件。但这实际上并不重要。磁盘空间便宜，源代码很小。 gitready.com/beginner/2009/02/17/how-git-stores-your-data.html
–詹姆斯
2011年10月6日在18:24
#7 楼
如此规模的小组没有源代码控制是正常的吗？绝对没有。当我在目前的公司工作时，只有一个人您应该将更改的代码发送给他，然后他将其合并。我可以说服大家在几天之内使用SVN。上面？
我认为您只听到模糊的原因是因为没有不使用版本控制的正当理由。
我还有其他理由需要进行源代码控制吗？可以添加到我的武器库中吗？
是的，原因很多。
分支使您可以开发新功能而又不干扰其他开发。
每次提交都会为您提供有关确切更改，更改的对象以及更改时间的信息。
您可以轻松地提交错误修正，并将其部署到客户，而不必未完成的新功能。
如果客户担心要使用较新的版本，则可以维护不同的版本。
您可以轻松地在同一项目（甚至是相同的源文件！）上使用k。
您可以轻松地还原错误，并保留已犯下的错误后的更改。
评论
“有一个人，您应该将您更改的代码发送给他，然后他将其合并” –听起来还不错。许多开源项目都以这种方式工作。您将补丁发送给维护者。但这显然不会扩展到大型团队。
– Alex Jasmin
2011年10月4日18:40
#8 楼
有些人很难意识到现状是多么糟糕，直到他们看到对自己更好的东西为止。您需要的是一个很好的演示。展示一些可以改进的实际任务示例。 “这花了我4个小时来追踪当前的系统，但是这个源代码控制命令立即告诉了我。”评论
我也将从中受益。我只读过源代码控制的好处，但从未亲身经历过。我曾考虑在家中设置SVN（但目前正在整理我的房子，并且没有太多时间..！）
– oliver-clare
2011年10月4日14:41
#9 楼
不使用源代码控制会提出问题，即使是对于单独的开发人员也是如此。您可以毫不留情地进行无情编辑的简单事实弥补了数周或数天的学习努力。帮忙，至少要在本地使用git或mercurial之类的东西-如果由于缺乏源代码控制而使事情破裂，至少您不会是这样做的人。评论
是的，没有理由不自己使用它，然后在他最不期望的时候向同事偶然展示它的功能。
–gtrak
2011年10月5日17:15
#10 楼
我公司使用GIT进行版本控制。该公司是一名开发人员，一名首席执行官，一名保安人员，一名清洁女工和一名接待员。他们都是我。源代码版本控制始终是必需的。#11 楼
我自己一个人从事很多项目，但我仍然使用版本控制。大小无所谓。进行版本控制总是有帮助的。在Joel测试中将它排在第一位是有原因的：http://www.joelonsoftware.com/articles/fog0000000043.html
此外，它还使列表中的＃2和＃3成为可能。
#12 楼
几年前，我们在一个由6人组成的团队中担任类似职务。一名开发人员采取了在共享文件夹所在的开发服务器上安装SVN的步骤，并开始使用它。彻底改变了我们的构建和发布流程，使其包括自动化和质量检查。#13 楼
WTF ？！这可能是我见过的最荒谬的问题。您需要找到新工作。 15位开发人员？您认为这是一个小团队？疯了吧。经理应立即终止。老实说，阅读完这个问题后，我将做噩梦。请告诉我们您出售的产品，所以我们都知道不买！我不知道这是什么吓人的问题，或者说这并不稀奇！#14 楼
我无法想象15个开发人员在没有任何源代码控制的情况下如何工作。但是，来自：（...）使用网络共享来托管其源代码（...）
我假设您已经创建了自己的穷人版本控件，例如VSS（也基于共享文件夹）。这是冒险的，效率不高。
向老板解释情况有多糟，投资一些为期2天的SVN或GIT培训，并在您的代码仍处于合理状态的同时开始使用实际版本控制系统。
评论
我不确定您需要两天时间来学习SVN。拥有15名开发人员，他们不可能全都“失学”。肯定有一半曾经在某个地方使用过它。
–迈克尔·布莱克本
2011年10月4日15:14
@MichaelBlackburn：我同意。我没有说清楚自己的意思。我当时想花2天时间进行培训和设置（设置存储库，导入代码等）
–MichałŠrajer
2011年10月4日16:19
#15 楼
如果我一天不做几次，或者至少在离开家之前，我会感到..缺少某些东西，出了些问题。我曾经在一家只有2个开发人员的公司工作（我+长发的管理员），早在1998年。即使如此，我们还是使用svn。太方便了。
我的职业生涯中有好几次都因为做了一些像mv而不是cp以及rm -rf的工作而失去了几天的工作。
我进入SE的13年里曾在5家公司工作，参加过一些会议，从未遇到没有使用版本控制的公司。 。
但是，我最喜欢的室内设计公司有20名员工，使用白板进行项目管理和协作。他们知道其明显的错误，但似乎没有时间升级。它以某种方式起作用。不要问我如何。
评论
svn在1998年并不存在。
– Faheem Mitha
2011年10月4日19:26
#16 楼
成为领导者。成为领导者意味着要做正确的事；主动解决问题。领导没有做任何事情，因为没有足够的共识。优秀的领导者会学会识别何时应该建立共识以及何时达成共识的情况。这显然是一个正在做的情况。缺乏代码控制的迟早会浮出水面。领导者通常不在官方管理职位上。人们会跟随好而果断的领导者，无论头衔如何。
如果您的决定性努力受到挫败，特别是如果来自管理层，那么这是您摆脱困境的明确标志。这会拖累您的专业发展；和称职的开发人员与不称职的管理人员混在一起，不称职的权力将使您陷入困境。
好吧，闪回正传给我。签字。祝你好运。
评论
谢了哥们。我喜欢领导者“做正确的事”的定义，不同于管理者“做正确的事”的定义。即经理正在以正确的方式来做自己正在做的事情，但这可能不是正确的事情。领导者做正确的事，但通常需要经理来做正确的事。绝对值得+1 :)
– oliver-clare
2011年10月7日，9：40
#17 楼
获取秒表，
计算您在电子表格中用于同步版本的时间
计算您在修复损坏的版本中花费的时间
计算次数人们在走廊上大喊“我正在编辑main.c !，只是为了确保现在没有其他人！”。
计算由于客户的错误修正包含其他更改而从客户那里收到的投诉数量
仅仅因为您无法同步版本来计算发布的时间延迟
使用此数据制作PowerPoint，并与vcs的工作方式进行比较。
显示管理
/>
#18 楼
这只是一场等待发生的事故。您没有代码历史记录，一口气，您的一名开发人员就可以消除数月的工作。作为一家小公司，您无法承受这种挫折。您也很容易受到这种共享驱动力的影响。即使备份良好，您还能承受多长时间不工作。 1小时1天1周。重新安装新服务器，从备份中还原等需要花费多长时间。同样，作为一家小型公司，您可能没有备用的备用硬件，并且可能无法轻易花钱来加快运输速度等。 br />
还要考虑异地存储。洪水或大火并不是那么罕见。如果下班后建筑物着火了，该怎么办。将会失去多少个月的工作。像github这样的托管代码存储库将对此非常有价值。即使在托管服务上使用简单的SVN服务器也将在这一领域迈出新一步。
#19 楼
LordScree，我的处境与您差不多，我的直属团队大约有15个开发人员。我难以置信（几乎感到恐惧）未使用源代码管理。我最初对“我们应该使用源代码控制”的回答是“我们没有时间实施”。对我来说，就像穿着内衣一样，源代码管理不是可选的。几个月后，我也获得了实施TFS的批准，该组织选择了TFS，因为它是MS，并且具有90天的试用期。底线是，很难让组织相信在没有源代码控制的情况下需要源代码控制。我告诉开发人员，只要您发现自己备份文件，尤其是备份的文件名或目录中带有日期，便是将某些内容放入源代码管理的示例。对于您，我没有任何出色的答案，但是我相信这并不常见。我正在同一个战斗中，将使您了解进度。而且，希望会有进展，否则我可能会在其他地方寻找，因为我无法在混乱中工作！评论
我认为，对于源代码控制，我最有力的论据是冒着没有源代码控制业务的风险。产品发行错误可能会花费大量的工作时间甚至几天的时间进行处理-更不用说与客户的关系受损了。如果没有受控的源代码控制，这是一个真正的风险，因为发布软件和跟踪每个客户的版本等所需的手动步骤数量众多。尝试从业务角度制定您的方法，因为经理们更愿意听这些论点，而不仅仅是“其他所有人都在使用它，所以我们应该这样做”。
– oliver-clare
2012年10月15日10:51
另一个促成因素的是，我的工作场所正在通过ISO 9001认证，这标志着IT企业由于缺乏源代码管理而陷入困境。认可对于投标新项目和商业伙伴关系很有用，因为招标文件经常会寻找这种东西。祝您战斗顺利！
– oliver-clare
2012年10月15日10:54
#20 楼
我们有3名开发人员，并使用源代码控制。在我的个人项目中，我只有一名开发人员，并且使用源代码控制。这不仅对团队管理有用，而且对能够从事实验工作而不用担心您要破坏某些东西很有用。说服管理的最简单方法是吗？整个产品的风险较小，从长远来看，它将提高开发人员的生产率。两者都是正确的，而且都吸引管理者。
#21 楼
这绝不是正常的情况，我认为您应该为在您的公司中获得此设置付出艰辛的努力。它具有深远的好处，在您接近世界末日时也没有实现相同的目的，也不会陷入困境。实施它只是做不好工作或过失的借口。只告诉他们今年1月1日发现该应用是什么了。嘿，此功能在三月份添加了，我认为我们需要对此进行更多扩展。
此提交中已修复此错误154256。
分支出应用程序并发送部署，没有问题的人可以继续进行下去。另一个问题）
#22 楼
我在一个人的项目和工作项目中使用版本控制，在这里，我们多达30至40个人同时处理同一代码。版本控制具有组织上的优势，但是还原文件和隐藏更改的功能确实可以使管理代码免除麻烦……最后，这对于程序员来说是最佳方案，因此他们可以专注于编码。 br />#23 楼
支持不使用版本控制的原因非常有限。我所能想到的只是事物的技术方面。 br />您的项目经理认为将开销引入管理和维护存储库的工作流程中并没有好处。 （主要是旧版本控制系统的问题）使用版本控制系统的原因很多。至少不要移动任何东西。使用补丁。版本控制系统可以完全按照您说的去做。
您可以在进行错误修复的同时使用下一个版本，并分别发布它们。
您可以创建一个分支，并在完成后将其合并到主目录中，而不必将文件从一个位置移至另一个位置。
每个开发人员都可以拥有自己的源代码副本，以防止出现相同问题项目在多台机器上打开。
发生事故，如果代码严重损坏，则只需回滚到上一个有效的修订版本号即可。
版本控制可与错误跟踪器和持续集成系统配合使用。 br />
作为一个人的团队，我个人使用版本控制，错误跟踪，持续集成，代码审查，代码一致性检查，单元测试，硒测试，源代码分析，还有可能我遗忘了更多内容。我承认，学习曲线有些许变化。您还需要权衡要自动执行的其他步骤所需的额外管理时间。以我的经验，节省的精力超过了额外的管理时间。
#24 楼
在1990年的第一份重要工作中，我是我部门中唯一的开发人员，不知道使用源代码控制。我几乎失去了那份工作的全部工作，因为我删除了错误级别的文件夹。幸运的是，我在一周前将副本放到5英寸的软盘上，并能够在几天之内重新创建一周的工作。是团队中每个人的第一个项目，没有人知道得更好，但是，即使一个人可以真正解释收益，而团队仍然不听，我会将对小组的看法从“幼稚”重新分类为“危险”不称职”（拒绝使用具有如此广泛展示的优势的工具几乎是犯罪行为–就像您的团队不信任“编译器”并坚持以汇编语言来完成所有工作一样。）
#25 楼
我在很多从事嵌入式软件/硬件开发的小型工程/电子公司中对此进行了很多研究。在这些地方，SCM并不是电子工程文化的一部分。他们通常每个项目只有一名工程师，他们只需要备份最新版本。
因此分支/合并甚至共享代码被认为是无关紧要的。另外，这些公司可能是ISO9000，所以这个过程可能很奇怪。
无论如何，我/其他开发人员只是开始亲自使用SCM。
#26 楼
在我工作的地方，我们有同样的问题。我目前正在尝试在“雷达范围内”滑动源代码控制，以解决您遇到的相同问题。我将化石用于自己开发的项目。我最近在公司LAN上安装了化石服务器，因此现在更加方便了。我希望当我在一些较小的项目上证明其有用之处时，我会破坏抵抗力，让我们摆脱网络文件夹的现状。使用化石或其他一些VCS的人是：
许多“程序员”都是脚本小子，不知道如何使用它。
那些可以学习，思考的人
这些人是老手，对网络文件夹很熟悉，所以每个人都应该
没有人有时间正确设置它，或者学习如何使用它
虽然功能可能很棒，但它们都不是必需的
如您所见，我试图通过证明它易于使用，已经设置，易于学习，并且这些功能完全值得。
最后，即使您不让它们使用源代码控制，也都在网络树中。 Fossil可以对整个树中的所有内容进行版本控制，您可以将其设置为在发生文件更改时（至少每小时）运行一次。对于某些“不需要源代码控制”的项目，我已经做到了，最终它使我可以在出现问题时回滚到一个好的版本。他们甚至都不知道您已经完成了。然后，您可以成为恢复已损坏构建的英雄，并演示您的工具多么有用。
#27 楼
既然已经有了Git和Mercurial之类的DVCS工具，并且它们的设置和使用极其简单，那么即使是1（！）的团队也不使用源代码控制，也确实没有任何借口。这与团队规模无关，而是与您的更改历史记录有关，以及支持工作流的能力，例如在处理新版本时修复生产问题，以及跟踪不同版本的源代码状态。如果提供给我的团队规模达到了这样的规模，并且没有一个开发人员建议使用VCS，或者如果“管理”阻止了他们，那么我会转平放下来。如今，这不是一种可接受的工作方式。
评论
使用Source Safe和SVN可以轻松设置版本控制。甚至CVS。 （在Windows环境中设置和使用Git并不容易）
– Tim
2012年10月2日15:04
#28 楼
您应该立即获得GIT版本控件。您甚至可以在Google Code Project Hosting中使用它。当其他人看到您在手动复制内容时只需单击一下即可提交更改时，也许他们改变了主意。评论
我完全同意。 Git安装程序非常易于使用，几分钟即可启动并运行。高级功能可以等待，基本版本控制不能等待。 cd toplevel目录; git init; git添加*; git commit -m“初始提交”
–除尘机器
2011年10月4日20:37
#29 楼
哇，哇虽然我认为这不是处理代码控制的最佳方法，但在一家有6个开发人员且未使用源代码控制的公司工作的情况下，这并非完全不寻常，他们有自己的内部文件管理方式，发行经理和什么都不会监督所有变化。实际上的口头禅是，只要围绕该功能包装了某种开关，就可以将新功能添加到项目中。例如，我们正在开发用PHP和PHP编写的AB级社交网络。客户端希望功能能够订阅用户个人资料。基本上，功能是这样封装的，如果（ENABLE_SUBSCRIBE_FUNCTIONALITY == true）{然后执行代码}特定文件，几乎所有内容都是模块化的，因此在这种情况下不需要源代码控制。但是，我相信在大多数情况下，源代码管理的优点远胜于不使用源代码管理的缺点。 Subversion可以为您解决这个问题，简直太荒谬了。
#30 楼
您似乎有些被说服，但是组织中的某人没有授权您执行此操作。正如您从其他评论中看到的那样，您应该这样做。您可以在此处找到一些信息：http://www.internetcontact.be/scm/?page_id=358
最重要的因素是，您的客户被迫进入最后一个“不稳定”的分支机构，并且如果您与客户的合同使您有责任部署不稳定的版本，那么您的公司就会亏本。您应该在这里真正关注发布稳定性。这是进行源代码管理的主要原因，而且似乎是您的主要失败。通过使用源代码控制，其他方面将不会有太多改善，因为您已经拥有替代系统。
评论
听起来他们离与Mercurial这样的DVCS合作并不遥远。如果将现有文件夹实际放入存储库中，那么拖脚的人可能仍在“使用” Mercurial。从他们的角度看，它几乎是相同的，如果没有，您可以提交更改。更新（我问这个问题后将近一年）：在过去的一年中，我一直在竞选，哄哄，乞讨和狂奔，直到我到了该死的地步为止，被自己的不服从命令几次。我很高兴地说，有关公司现在终于认真考虑了源代码控制，以期在一个月左右的试用期后实施TFS，同时我们确保所有开发人员对新流程感到满意。在很大程度上，我从程序员这个问题上得到了我的积极回应，这使我有信心去追求它。干杯。
不使用源代码控制的开发人员等同于外科医生不洗手或使用脏器进行操作。这是专业上无能为力的事情，没有理由为这种渎职行为提供理由。
尽管电力是很久以前发明的，并且在我们的日常生活中无处不在，但仍有一些人仍然选择使用尖的棍棒在蜡板上的烛光下书写代码。
15个开发人员并不是小商店。