[pixeldude]

Thanks for your feedback! I completely understand your point. Maybe it would make sense to make another guide with an intro on Source Control Management systems and link it in the git guide. Currently, you need to have a little bit of knowledge on an SCM. But I will think about it.

[skrebbel]

Hmm, I'm not sure "having a little knowledge on an SCM" does the trick. Let's assume that I've used subversion for years (which surely is SCM). Therefore, for instance, I know that a repository is something on a server that can hold all relevant for my current team (we'll checkout a subdir for each of subproject). Also, I know that committing means sending a change to the server. I also know that I can lock a file and then nobody else can commit it, handy!

The meaning of nearly all SCM-related terms in your tutorial are highly git-specific. Making an SCM intro does not really help that. You need to make a git intro.

[markkanof]

I don't know if they are necessarily Git specific, but probably are distributed version control system specific. For example the concept that committing would record your changes to the local repository wouldn't make any sense to a Subversion user, but would make a lot of sense to say a user of Mercurial.

[pixeldude]

Yes, you might be right on this. I will think about it. If you have links where something like this can be found, i would appreciate it. Thanks!

[kalid]

Hi, shameless plug but I've found people enjoyed these two guides on traditional version control and distributed version control:

http://betterexplained.com/articles/a-visual-guide-to-versio...

http://betterexplained.com/articles/intro-to-distributed-ver...

One technique I use is trying to explain the underlying concepts using analogies to what people already know. Most people are familiar with using "Save as..." to create MyResumeOct2010.doc, MyResumeFinal_v1.doc, MyResumeFinal_REALLY.doc, etc. Version control is like a beefed up, automatic "Save as...". You can jump to any version without a mess of different files.

Distributed version control lets you "peel off" individual changes and send them to anyone. If you are making a shopping list with 3 people, you can "peel off" the items that Alice, Bob and Charlie added and put them on your own list.

Once the concepts are clear, you can give them proper names (diffs, revisions, commits, etc.) and things start to click. Anyway, that's what I've found helpful, good luck!

[dgallagher]

I found this guide very useful, so thanks for making it. :) I've used SVN, Mercurial, and git before, so knowing those made this easy to digest. Plus it covers stuff about git I never knew existed, like gitk. So cool!