我相信每个人都知道源代码管理是负责任的软件开发的核心组成部分。与软件开发实践一样，大多数组织在使用他们选择的源代码控制管理工具时有不同的政策和程序；颠覆、GIT、TFS 等
我的问题是您如何为源代码控制管理领域的新员工和现有员工提供培训？您是否提供员工文件、视频、棕色包会议、来自认可提供商的正式培训或其他什么？
问问题
366 次
3 回答
4
我提供的培训（一次正式培训，附带一些幻灯片）主要围绕发布管理流程。
这意味着我没有过多展示我们使用的 VCS 的基本功能（无论如何用户很快就会弄清楚），但我坚持要如何使用 VCS 功能来生成版本（这就是所有开发的内容关于：如果您不在生产中发布某些东西，那么整个游戏都是毫无意义的）
所以：
- 你什么时候应该分支，为什么？
- 你什么时候应该合并，为什么（不是那么多）？
- 你的交付（二进制文件、战争、罐子、耳朵）应该去哪里（提示：不在 VCS 中）
- 你应该从哪里获得所有依赖项。
换句话说，我试图坚持 VCS 不是管理的额外障碍，而是促进下一个版本的工具之一。
注意：这是一个以企业为中心的观点（许多内部项目依赖于许多其他内部项目），并且可能与分散的开源开发项目（一个项目通常——并不总是——单体）有很大不同，只有库外部依赖项）。
于 2010-11-09T09:10:40.180 回答
1
在我们的组织内，我们确定了两组 SCM“消费者”，并针对每一个组定制了我们的培训。
SCM 协调员不仅要知道我们用 SCM 做什么，还要知道我们为什么要这样做。期望他们了解我们的分支方法，并且知道如何在工具内和命令行中进行合并。它们是我们在开发战壕中的第一道防线。
开发人员应该知道如何“获取”、“签出”和“提交”。他们应该对我们的分支方法有较高的了解，以便知道在哪些分支中工作，并且他们需要知道如何使用集成的 SCM UI 与存储库进行交互。
我们的SCM 协调员是一些精心挑选的资深人士，我们给予（并继续给予）他们密切的一对一帮助以帮助他们学习。
我们的开发人员获得了一份 PowerPoint 幻灯片，并且（希望）与他们的 SCM 协调员进行了一对一的交流。我认为开发人员 PowerPoint 套牌大约有 15 页 18 点类型。
到目前为止，这已经取得了很好的效果。我的主要建议是确保不要让不需要知道 SCM 详细信息的人不知所措。我注意到一般人在 SCM 讨论后的大约 5 分钟内就会目瞪口呆并打瞌睡。
于 2010-11-09T13:27:50.760 回答
0
您正在寻找什么样的培训？特定于您的策略或源代码控制系统？
如果您想要一个总体概述，请查看 Eric Sink 的Source Control HOWTO。它较旧，因此我认为不包括分布式版本控制。
于 2010-11-19T21:04:29.597 回答