The training I give (one formal training, with some slides) is mainly centered around the release management process.
It means I don't so much show the basic function of the VCS we use (the user figure them out pretty quickly anyway), but I insist on how the VCS features are used to produce a release (which is what all the development is about: if you don't ship something in production, the all game is kind of pointless)
where your deliveries (binaries, war, jar,ear) should go (hint: not in a VCS)
where should you get all your dependencies.
In other word, I try to insist on how the VCS is not an extra obstacle to manage, but one of the tool there to facilitate the next release.
Note: this is an enterprise-centric point of view (where many internal projects depend on many other internal projects), and can be very different from a decentralized open-source development project (where a project is often -- not always -- monolithic, with only libraries external dependencies).
Within our organization, we identified two groups of SCM "consumers," and tailored our training to each of those groups.
SCM Coordinators are expected to know not only what we do with SCM, but why we do it. There's an expectation that they understand our branching methodology, and that they know how to do merges within the tool and at the command line. They are our first line of defense in the development trenches.
Developers are expected to know how to "get", "check out," and "commit." They should have a high level understanding of our branching methodology so they know which branches to work in, and they need to know how to use the integrated SCM UI to interact with the repository.
Our SCM Coordinators were somewhat hand-picked senior people, and we gave (and continue to give) them close one-on-one assistance to help them learn.
Our Developers get a PowerPoint deck and (hopefully) some one-on-one time with their SCM Coordinator. I think the developer PowerPoint deck is about 15 pages of 18-point type.
Thus far, this has worked out pretty well. My main recommendation is to make sure you don't overwhelm people with the SCM details if they don't need to know it. I've noticed the average person glazes over and dozes off within about 5 minutes of SCM discussion.
发布评论
评论（3）
我提供的培训（一次正式培训，带有一些幻灯片）主要围绕发布管理流程。
这意味着我并没有太多展示我们使用的 VCS 的基本功能（无论如何用户很快就能弄清楚它们），但我坚持如何使用 VCS 功能来生成版本（这就是所有开发的目的）关于：如果你不在生产中交付某些东西，那么所有游戏都毫无意义）
所以：
换句话说，我试图坚持认为 VCS 不是一个额外的管理障碍，而是促进下一个版本发布的工具之一。
注意：这是一个以企业为中心的观点（其中许多内部项目依赖于许多其他内部项目），并且可能与分散的开源开发项目（其中一个项目通常（并非总是）是单一的）有很大不同，仅具有库外部依赖项）。
The training I give (one formal training, with some slides) is mainly centered around the release management process.
It means I don't so much show the basic function of the VCS we use (the user figure them out pretty quickly anyway), but I insist on how the VCS features are used to produce a release (which is what all the development is about: if you don't ship something in production, the all game is kind of pointless)
So:
In other word, I try to insist on how the VCS is not an extra obstacle to manage, but one of the tool there to facilitate the next release.
Note: this is an enterprise-centric point of view (where many internal projects depend on many other internal projects), and can be very different from a decentralized open-source development project (where a project is often -- not always -- monolithic, with only libraries external dependencies).
在我们的组织内，我们确定了两组 SCM“消费者”，并针对每一组定制了我们的培训。
SCM 协调员不仅要了解我们使用 SCM 做什么，还要了解我们为什么这样做。我们期望他们了解我们的分支方法，并且知道如何在工具内和命令行中进行合并。他们是我们发展战壕中的第一道防线。
开发人员应该知道如何“获取”、“签出”和“提交”。他们应该对我们的分支方法有深入的了解，以便知道要在哪些分支中工作，并且需要知道如何使用集成的 SCM UI 与存储库进行交互。
我们的SCM 协调员都是精心挑选的资深人员，我们为他们提供（并将继续提供）密切的一对一帮助，以帮助他们学习。
我们的开发人员获得了 PowerPoint 演示文稿，并（希望）与他们的 SCM 协调员进行了一对一的交流。我认为开发者 PowerPoint 大约有 15 页 18 点类型。
到目前为止，这已经取得了很好的效果。我的主要建议是确保您不会让不需要了解 SCM 详细信息的人们不知所措。我注意到一般人在 SCM 讨论后大约 5 分钟内就会变得呆滞并打瞌睡。
Within our organization, we identified two groups of SCM "consumers," and tailored our training to each of those groups.
SCM Coordinators are expected to know not only what we do with SCM, but why we do it. There's an expectation that they understand our branching methodology, and that they know how to do merges within the tool and at the command line. They are our first line of defense in the development trenches.
Developers are expected to know how to "get", "check out," and "commit." They should have a high level understanding of our branching methodology so they know which branches to work in, and they need to know how to use the integrated SCM UI to interact with the repository.
Our SCM Coordinators were somewhat hand-picked senior people, and we gave (and continue to give) them close one-on-one assistance to help them learn.
Our Developers get a PowerPoint deck and (hopefully) some one-on-one time with their SCM Coordinator. I think the developer PowerPoint deck is about 15 pages of 18-point type.
Thus far, this has worked out pretty well. My main recommendation is to make sure you don't overwhelm people with the SCM details if they don't need to know it. I've noticed the average person glazes over and dozes off within about 5 minutes of SCM discussion.
您正在寻找什么样的培训？具体到您的政策或源代码控制系统？
如果您想了解总体概述，请查看 Eric Sink 的源代码控制指南。它比较旧，所以我认为没有涵盖分布式版本控制。
What kind of training are you looking for? Specific to you polices or to your source control system?
If you want an general overview check out Eric Sink's Source Control HOWTO. It is older so I don't think distributed version control is covered.