I've been asked to do a one-lecture (50 minute) presentation on Version Control. In the class we'll be using Git; there will be a hands-on opportunity to work with Git later in lab. (The Git GUI of choice of the professor is GitKraken).
I don't need to teach anyone to be Git Wizards. I'm not a git wizard myself. But I need to show the class what version control can do, and the basics of using Git to collaborate between multiple people.
@si618 provided a wonderful "Why use VCS" over on StackOverflow, which I am going to borrow (with credit, obviously, the CC license requires it). That covers the motivation portion.
Then I need to cover the actual model of sharing code via VCS. That's the hard part. LearnGitBranching is a wonderful resource I'll likely use to show commits and branches, but the main use of that site seems like (to me) experimenting with more complicated rebase-based operations. And a quick here's-what-vcs-is doesn't (shouldn't) need to rewrite history.
Explaining the model is the hard part; showing the application of the model is simple since I'll likely use the GUI. The command line interface isn't of import. But what really needs to be understood to understand a DVCS model?
commit-- add snapshot to your local history
push-- publish your local history to some location
pull-- download history from some source
branch-- split the line of history into two "timelines" for concurrent work
merge-- collapse bring two parallel histories into one
Is there anything else that really should be covered? These five seem like the key components. Is it worth mentioning that every local
master downloaded from the repository is a new copy, and is effectively a branch
origin/master -> local/master? Is it worth mentioning that a headless git repository is no different than a local one, and that you can pull directly from a non-origin repo? Merge conflicts happen; should I mention how to go about resolving those?
Distilling an (admittedly shorter than my seniors') career of working with Git into a short "Here's why Git is awesome and you should use it" is difficult. I want to teach Git (and more generally, VCS) and not just "how to use GitHub". Thinking Git === GitHub is one of my pet peeves.
The structure of the course itself is rather open-ended: the second half of the course is opportunities for students to share something they've spent some time learning on their own (that's where I fit in). Since I potentially have the greatest cross-section of teaching ability and domain knowledge among the students, I was asked by the professor to do a section on Git before the lab where people get to try it out themselves. During that time as well, students will be working in groups to complete a large assignment, so I definitely want them to use some sort of VCS; it'll save everyone a bit of trouble.
The course is an upper level university CS elective.
I believe the two questions are meaningfully different. The other question addresses a (self) learning approach while this question seeks a teaching approach.
More importantly, answers on either question aren't generally applicable to the other. Trivial answers may be able to answer both, but any real meat on an answer makes it only really applicable to one question.