如何鼓励采用版本控制

我最近开始在没有版本控制的团队中工作。大多数团队成员都不习惯任何版本控制。我一直在私下使用Mercury跟踪我的工作。我想鼓励其他人采用它，并且至少在开发变更时开始对他们的代码进行版本控制。任何人都可以给我一些建议，以鼓励我采用诸如Mercurial这样的分布式版本控制。任何有关如何赢得包括DVCS经理在内的人员的建议，将不胜感激。

您需要说明使用版本控制的理由，首先尝试将其出售给您的同事，如果失败，则向上推至项目领导者及更高级别。

对于其他软件工程师来说，您的案例应侧重于从长远来看如何节省时间和麻烦。寻找过去的时光或发布的故事（博客，杂志文章，白皮书）中有关使用版本控制如何使您的生活更轻松的时间。如果您因没有版本控制而烦恼，请使其个性化。如果您的其他开发人员也处于同样的情况，那么他们应该了解情况以及这些工具如何为他们提供帮助。

这是你最好的选择。尽管我现在找不到源，但我已经（在几个地方）读到，最有效的流程更改来自开发人员，他们必须处理这些更改。如果您可以聘请开发人员，那么您将实现两件事。首先，您已经获得了将受到流程变更影响的人员的支持。其次，有一群人说服管理层，这是值得的，并将改进产品和项目。

但是，如果您无法获得开发团队的支持，并且仍然对部署版本控制感到非常难以置信，那么您可以升级到管理。但是，如果您单打独斗，则风险会更大，因为您不仅要担心出售改进，而且还要应对同事的强烈反对。

为了进行项目，程序和组织管理，必须以部署版本控制如何节省组织时间和金钱为例。这个级别的人关心项目要花费多少钱，与估算相比要保持的水平等等。查找白皮书，书籍，文章以及其他专业文档和出版物，这些白皮书和出版物解释了从长远来看部署版本控制如何为其他组织节省时间和金钱。如果您的组织对软件质量感兴趣，还可以在此处介绍质量观点。

您特别提到要使用分布式版本控制系统。不要强迫团队或组织这样做。向他们介绍版本控制及其选项。尽管您个人可能更喜欢使用DVCS（例如Mercurial），但它可能不是最适合您的团队和组织的方式。使用不合适的工具只会使打动变得更糟。

另外，请注意后期引入流程的风险。尽管使用版本控制是一种普遍接受的最佳实践，但是在当前项目中有效地引入它而又不会给项目完成带来巨大风险的情况下，为时已晚。相反，我建议重点关注改善未来项目和团队的现状。

同样，这是执行任何过程或技术改进时可以遵循的通用方法。

第一个问题是：他们目前正在做什么？当然，每个开发人员都不会将源代码粘贴在自己随意更改的盒子上。一旦了解了他们当前遵循的流程，就可以建议一些可以增强该流程的工具-通常，SCM是帮助他们完成此工作的理想选择，而不是让他们遵循不同的流程。

这里的要点是，如果它们具有伪SCM的工作方式，也许将当前版本存储在某处的服务器上，则您需要确定DVCS或CVS是否更合适，不要尝试将它们出售给Mercurial。如果SVN更合适。

最快的方法是说服管理层需要它。

做一些计算：

版本控制软件的成本-免费。
支持存储库的硬件成本-一台服务器。
实施软件的成本-一个小团队需要花费几天的工时，而较大的团队则需要增加工时。

不实施版本控制的成本：

最好的情况-由于缺少编辑，覆盖彼此的更改等，错误反复发生而导致的损失天数。
最坏的情况-到目前为止，您的团队花费了很多精力。

后一个数字是最坏的情况，由于服务器故障等原因，您失去了所有工作。但是即使是“最坏的情况”，也应该使他们明白为什么需要这样做。重复出现错误的成本可能更高，因为它可能导致客户流失。

开发团队还应该了解这些成本，并且鉴于当今大多数（如果不是全部）版本控制软件与IDE无缝集成，他们甚至在大多数时间都不会注意到它。

管理层通常最关心存钱。强调版本控制如何为团队带来经济利益，您将立即获得他们的关注！

这里的其他人没有谈到的一个方面是，我认为您已经进入了困境-您在谈论分布式版本控制-就其本质而言，您可以将其潜入一种实际的实践中，一个开发人员一次。使用更闷的版本控制（例如我们在办公室中使用的版本控制（MS Visual SourceSafe）），您将很难走到我对面那个多维数据集上的那个家伙，并根据自己的优点一对一地卖给他版本控制。但是，使用（任何）DVCS，您可以说“嘿，尝试一下，看看您是否喜欢它。我会给您看的绳子，我很乐意回答任何问题，向您介绍，等等。等等”。这样，您不需要从头到尾的“过程”，您可以一次建立一个基层的任务。

建立在gbjbaanb的答案上。

这里的关键是您应该使版本控制过程适应现有的任何过程，并说明它如何节省团队的其他工作。

我个人也赞成Mercurial，但我不一定要把它强加给不习惯版本控制的人，因为它比起老式的基于服务器的锁定版本控制系统更难理解。就是说，如果这是一个真正的绿地网站，最好是全力以赴，跳过80年代和90年代，选择Mercurial。我还会看一些围绕Mercurial构建的第三方软件生命周期的东西-我敢肯定有一个东西，但是它的名字让我忘了;）

我猜您是在一家小公司工作，而且您是团队中的新手，所以这可能很难卖出-特别是如果团队中的其他人根深蒂固并获得管理层的信任。最好让他们把东西塞坏，然后再进行救援。这并不意味着破坏，只是等待不可避免的情况。