如何说服牛仔程序员使用源代码控制？

更新
我在一个由4个人组成的小型开发团队中工作。他们都使用了源代码控制。他们中的大多数人不能忍受源代码管理，而是选择不使用它。我坚信源代码控制是专业发展的必要部分。有几个问题使得说服他们使用源代码管理非常困难：

• 该团队不习惯使用TFS。我进行了2次培训，但只分配了1个小时，这是不够的。
• 团队成员直接在服务器上修改代码。这样可以使代码不同步。要求比较只是为了确保您正在使用最新的代码。并出现复杂的合并问题
• 开发人员提供的时间估算不包括解决这些问题所需的时间。因此，如果我说诺诺，则需要花费10倍以上的时间...我必须不断地解释这些问题并冒险冒险，因为现在管理层可能会认为我“慢”了。
• 服务器上的物理文件超过100个文件以未知的方式有所不同。合并需要了解手头的项目，因此需要我无法获得的开发人员合作。
• 其他项目不同步。开发人员继续对源代码管理不信任，因此不使用源代码控制使问题更加复杂。
• 开发人员认为，使用源代码控制很浪费，因为合并容易出错并且很困难。这很难辩驳，因为当源代码控制被严重滥用而源代码控制被不断地绕开时，它确实容易出错。因此，证据在他们看来是“不言而喻”。
• 开发人员认为，绕过TFS直接修改服务器代码可以节省时间。这也很难争论。因为开始同步代码所需的合并非常耗时。乘以我们管理的10多个项目。
• 永久文件通常与Web项目存储在同一目录中。因此，发布（完全发布）会删除这些不在源代码管理中的文件。这也加剧了对源代码控制的不信任。因为“发布破坏了项目”。解决此问题（将存储的文件移出解决方案子文件夹）需要花费大量时间和调试时间，因为这些位置未在web.config中设置，并且通常存在于多个代码点中。

因此，文化会持续存在。不良做法会导致更多不良做法。不良的解决方案会驱使新的黑客“更正”更深层次，更耗时的问题。服务器，硬盘空间极难获得。然而，用户的期望正在上升。

在这种情况下可以做什么？

这不是培训问题，而是人为因素问题。他们不愿意，正在制造障碍。应对破碎的群体动力，他们反对的根本原因是什么-通常是恐惧，仅仅是害怕改变，还是更加险恶。

今天或过去20年来，没有专业开发人员抵抗源代码控制。大约在30或40年前，当计算机运行缓慢，源代码控制甚至更慢并且程序包含一个500行文件时，这很痛苦，并且有充分的理由不使用它。这些异议只能来自我能想到的最糟糕的牛仔。

系统是否强迫他们以某种方式使他们的生活变得困难？找出问题所在，然后更改系统以使异议无效。重复直到完成。

我建议您查看GIT或Mercurial。您可以在每个源代码树中创建一个存储库，他们甚至不会注意到它们，并且可以继续修改它们现在的方式。您可以跟踪他们入侵到代码库中的更改，进行提交，将它们合并到其他源代码树等​​中。当他们看到您在几秒钟内将价值数周的工作合并到另一个产品中时，他们可能会改变他们的想法。当您使用一个命令回滚他们的其中一个螺丝钉并保存他们的屁股时，他们甚至可能会感谢您（不要指望）。最糟糕的是，你在老板面前看起来不错，而且有一个红利，使他们看起来像牛仔。

合并不仅需要大量的项目知识

那样的话，恐怕你在没有桨的小河上。如果合并不是一种选择，那么也不会实现，因此，您是说您不能再将一个分支（已广泛使用的术语）中已有的功能添加到另一个分支中。

如果我是你，我会重新考虑我的职业前景。

有时，现实世界中的问题使其难以使用。

假。

如果团队不习惯使用源代码控制，则会出现培训问题

这与源代码控制无关，而与培训无关。培训简单，便宜，高效，并且只需几个小时即可完成。没有使用源代码控制的成本很高，风险很大，效率低下，问题仍然存在永远。

如果团队成员直接修改服务器上的代码，则会出现各种问题。

那是培训问题。再次。与源代码控制无关，与培训无关。

开发人员继续对源代码管理不信任，因此通过不使用源代码控制使问题更加复杂

他们需要接受有关如何使用源代码控制的培训。它降低了成本，降低了风险，简化了工作并提高了效率。这是一项一次性投资，每时每刻都在分红。

在这种情况下可以做什么？

开始培训每个人如何使用源代码控制。

更新资料

开发人员认为，直接修改源代码控制可以节省时间。

由于它们是错误的，因此重要的是收集数据以准确显示这是多么的错误。

然而，令人遗憾的是，管理层似乎会奖励立即作出的回应，这从长远来看代价很高。

克服这种奖励制度的唯一方法是

A）确定长期成本高于表观短期价值。

B）确定使长期腐败（即直接变更）显得比长期正确的源代码控制更有价值的实际奖励。谁因做错事而轻拍头部？他们会得到什么样的头部轻拍？谁给的？为了解决问题，您必须命名错误的事物，并具体说出那些实际上在鼓励人们的经理。

C）推荐修订后的奖励系统，该系统重视长期价值而不是短期快速反应。由于不同的原因，头部会发生不同的拍打。

D）培训人们获得长期价值的奖励；该值明显大于短期快速响应。

拒绝使用源代码/版本控制的开发人员应该被解雇，就这么简单。正如您已经指出的那样，不使用它的固有风险和成本要比它产生的任何额外费用高很多数量级。试图反对这一点的任何人都不应参与软件开发，而我会拒绝与这些人一起工作。

我们首先解决了该问题，设置了一个持续集成服务器，以将源代码控件构建到开发人员中。其次，将文件夹访问权限锁定为只读，以防止人们绕过源代码管理并直接修改文件。

在有些日子里，这是PITA，您无法在本地重现该错误，但除此之外，它能够工作，签入和继续运行会更好，因为它知道CI服务器会自动将其推送到开发人员手中。

我听到你的痛苦。我走进了几个工作场所，发现“源代码控制”是网络驱动器上的共享文件夹。问题通常不是因为他们认为这种方法比其他任何方法都优越，它只是行之有效，而且从未将它们引入成功集成源代码控制的工作流中。

对于扁平的团队结构，您已经说明了从上到下推动变更可能不是解决情况的最佳方法。值得尝试的一种方法是直接从其他一个或两个开发人员那里购买，以使这一概念积聚力量。一旦您拥有其他开发人员，将其传播到团队的其他成员将变得更加容易。慢慢地向他们介绍这个概念，比如说开始进行一个小型项目，启动它并进入Git，甚至分支一些托管在GitHub上的东西。

从简单开始，慢慢地，与日常工作流程分开介绍概念。人类擅长学习事物并适应变化，特别是当变化为他们带来直接好处时（思考进化）。但是，当立即呈现一堆小变化时，它就会变得疏远。一旦他们掌握了源代码管理的工作原理以及它提供的优势，然后尝试将其集成到您的内部项目中（如果您开始一个新项目，这是一个引入它的邪恶时机）。如果您愿意，还可以让其他项目以现有方式运行，这在突出体面代码控制的优势时特别有效。

如果失败，请运行。

您显然具有识别和解决情况的技术能力，您的问题与人为和流程相关。

人们对示例的反应往往比对视觉的响应要好得多，所以我建议自己“修复”它：

拿一份最新源代码的副本，重新构建它以使其易于版本控制，创建一个有用的，具有前瞻性的结构的新项目（了解如何处理分支，放置第三方依赖等）。您可能必须在自己的时间内执行此操作。

然后将您的同事和管理人员拖入一个房间，向他们展示 21世纪软件开发的样子。说明您当前系统的故障，并说明如何通过新结构消除故障。

您还必须将自己设置为“源头守护者”-由于您似乎是唯一在乎的人，因此，您必须迫使人们（使用任何技术或心理手段）坚持执行计划。确保发给客户的唯一东西是来自源代码控制之外的构建机器。在礼节上侮辱违反规则并造成破坏的人。用甜甜圈贿赂他们……不管用什么。

如果这一切看起来都太费力了，那么（就像在其他所有答案中都说过的那样）-再找一份工作。他们不值得你花时间。

第1步-解雇无能的经理！

如果您无法执行步骤1，请尝试让管理器将部署限制为仅从源代码管理中获取脚本。如果开发人员（他们不应该拥有产品的生产权，请参见步骤1），则他们希望部署的东西必须来自源代码控制。这就解决了我们第一次将数据库和C＃代码用于源代码控制时就没有很好地使用源代码控制的问题。

有人不希望他们的文件具有不同的版本以及看到差异的能力？忘记分支和任何复杂的东西。他们甚至不了解基础知识。直接修改生产文件而不在测试环境中进行最基本的更改是很疯狂的。我曾与一些人一起工作过，幸好我们从未在相同的项目上工作过。

您的同事太愚蠢而不能偷懒。那是浪费时间。您所希望做的就是培训您的经理。管理层应该喜欢源代码控制，因为他们喜欢所有形式的控制。使他们感到重要。拧其他；固定领导者是您唯一的希望，因为您无法替代他。开始与其他有能力的开发人员建立联系，或者尝试让他们在开放时加入您的团队，或者让他们在他们的商店雇用您。

这是一个项目的一个很好的例子，其中普遍采用了不良做法，因此几乎不可能对其进行修复。对其进行修复将需要冻结，因此可以无中断地清理所有内容。不幸的是，这样的项目通常（由于明显的原因）有太多的错误，无法冻结几个月，因此必须每隔一天修复关键的错误。

您可能很想让项目创建一个干净的版本，而用那些日常的错误修正来处理不干净的版本。但是最有可能的结果是，几个月后，“干净”版本完成后，没有人能告诉您自分叉以来哪些错误修正和更改不正确（因为相同的观念会让人们陷入这种做法中，因此不太可能他们保留有关所做更改的记录）。干净版本已经过时，脏版本仍然可以使用，那么会发生什么呢？干净的版本被丢弃了，反对者证明是正确的。

除了显而易见的找到新工作以外，我认为答案还不止上述。

首先，请管理层进行迁移，并加强对源代码控制的使用，以使他们参与其中。然后继续进行必要的工作以保持运行，即使这意味着直接在服务器上工作也是如此。开始在源代码管理中获取所有内容的过程。

另一个选择是确保服务器上有最新版本（无论如何都必须这样做），然后从最新版本开始完全启动新的存储库。您将失去历史，但在这一点上，这是小土豆。

从您的描述看来，这种情况存在一个或多个问题-开发团队失控或实施了不良的源代码控制解决方案。无论哪种方式，开发团队都有责任使用一些源代码控制解决方案-直接在生产服务上修改源代码只是在乞求问题的发生。

根据我的经验，必须立即进行的第一步是将源代码控制与生产服务器同步。这一步很简单，只需复制生产代码并检入-产品代码可能是您团队开发的基础。可能需要通过与现有源代码管理系统中浮动的代码合并来增强此步骤。代码应从开发人员流到集成/质量保证（或两者），然后流到阶段或阶段/生产。

接下来，管理层需要强制使用源代码控制。很简单，如果构建不是来自源代码控制系统，则不应将代码部署到生产中。生产访问权限仅应仅限于支持团队，而对开发人员进行生产问题排查的访问权限也有限。开发人员通常不应该将代码热部署到生产中-肯定会发生生产问题，尤其是在开发人员承受压力的情况下。

管理层肯定需要更好地处理这里的问题-如果将代码直接应用于产品（而不是进入源代码控制），几乎不可能维持开发。

真正的问题不是牛仔编码器不使用版本控制。真正的问题是他们已经选择了某种处理方式，而您正在尝试更改他们的流程。所选过程不包括版本控制。除非程序员自己注意到问题，否则所有过程更改都是困难的。如果觉得现有系统足够好，那么强加一些不同的系统就是徒劳的。我们是博格，您将被同化。当然，他们正在努力成为博格。

为了您自己的理智，建议您在自己的计算机上设置Git或其他DVCS，以便您可以跟踪更改。经常将同事的更改导入到您的存储库中。尽力解决冲突。这将部分使您免受同事的理智困扰。

您已经提到管理层说开发人员应该使用源代码控制。如果您想作恶，则可以通过将更改签入TFS并定期发布存储库来强制实施，从而破坏TFS中没有的任何更改。（如果您还维护自己的DVCS，则应使两者保持同步。）这样做的理由是您遵循管理层的命令。如果您的同事厌倦了他们的更改被覆盖，请邀请他们使用TFS。并保持未经检查的更改。继续进行直到您的同事松懈或您被解雇为止。

锁定除服务器以外的任何服务器。使用配置管理器。进行常规的可识别构建（针对标签）。标记每个变更集（即每个错误1个变更集）。我们还在每个构建上放置一个标签。在开发人员和生产人员之间至少要有一个质量检查类型系统。使用正确的构建标记来构建QA系统。让他们为“破坏体系”感到悲伤。

我从未遇到无法重新创建/解决问题（仅在生产环境中显示）的情况。是的，我花了数小时使问题在开发系统上重新创建（加上您发现问题后可以将其添加到回归测试中）。

我们与一群牛仔承包商一起完成了一个项目，这些承包商做了所有这些坏事。此后，我花了4周的时间进行清理，然后将上述做法付诸实践。从那时起，该项目就没有任何问题。

引用：

团队不习惯使用TFS

TFS证明是Microsoft Team Foundation Server。

我的第一个直觉是：“这是Microsoft Visual SourceSafe的最新版本”

我会在你们同事的身边，坚决反对这一点。