Source Control Training [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

开发者_运维问答

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 9 years ago.

Improve this question

I am sure everyone knows that Source Control is a core component of responsible software development. Like software development practices most organisations have differing policies and procedures in working with their chosen Source Control Management Tool; Subversion, GIT, TFS, etc.

My question is around how you provide training for new and existing staff in the area of Source Control management? Do you provide staff documentation, videos, brown bag sessions, formal training from an accredited provider or something else?

---

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:

• when should you branch and why?
• when should you merge and why (not so much how)?
• 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.

---

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.