源控制培训

我提供的培训（一次正式培训，一些幻灯片）主要围绕发布管理流程。 这意味着我没有那么多地展示我们使用的VCS的基本功能（用户无论如何都非常快速地将它们弄清楚），但我坚持如何使用VCS功能来生成一个版本（这就是所有的开发都是关于：如果你不在生产中运送东西，那么所有的游戏都是毫无意义的） 所以： 什么时候应该分支？为什么？ 什么时候应该合并？为什么（不是那么多）？ 您的交付（二进制，战争，罐子，耳朵）应该去哪里（提示：不在VCS中） 你应该在哪里获得所有依赖项。 换句话说，我试图坚持VCS如何不是一个额外的管理障碍，但是其中一个工具可以促进下一个版本的发布。 注意：这是一个以企业为中心的观点（许多内部项目依赖于许多其他内部项目），并且可能与分散的开源开发项目（项目经常 - 并非总是 - 单片）非常不同，只有库外部依赖项）。     

在我们的组织内，我们确定了两组SCM“消费者”，并为每个群体量身定制了培训。 SCM协调员不仅要了解我们对SCM的处理方式，还要了解我们为什么这么做。期望他们理解我们的分支方法，并且他们知道如何在工具和命令行中进行合并。它们是我们在发展战壕中的第一道防线。 期望开发人员知道如何“获取”，“检查”和“提交”。他们应该高度理解我们的分支方法，以便他们知道哪些分支可以使用，并且他们需要知道如何使用集成的SCM UI与存储库进行交互。 我们的SCM协调员是一些精心挑选的高级人员，我们给予（并继续给予）他们一对一的帮助以帮助他们学习。 我们的开发人员获得了一个PowerPoint套牌，并且（希望）与他们的SCM协调员一对一。我认为开发人员PowerPoint套牌大约有15页的18点类型。 到目前为止，这已经很好了。我的主要建议是确保如果他们不需要了解SCM详细信息，请不要压倒他们。我注意到普通人在SCM讨论的大约5分钟内釉面并打瞌睡。     

你在寻找什么样的培训？特定于您的政策或您的源控制系统？ 如果您想要概述，请查看Eric Sink的Source Control HOWTO。它比较旧，所以我认为不包括分布式版本控制。