One lecture on VCS: What needs to be covered?
As requested, I'm expanding my comment into an answer. This is going to echo a lot of what I said in this answer, so you might also check that out for some background motivation.

Version control systems are tools that are designed to solve specific problems.

They're great for stuff like:


Storing multiple revisions of a file.
Allowing collaboration among multiple people.
Handling cases where multiple people are editing the same file or even the same section of code.


If the students haven't encountered these problems, then they might not be ready to start using a version control system.

Another consideration is that students need to understand basic directory and file structure interaction before diving into version control. Do they know how to navigate a directory structure? How to edit and copy files? This is less "common sense" than you might expect, but it's definitely a prereq to talking about version control.

All of that being said, I think you should start by explaining the above problems. Discuss how they might "solve" those without version control. Ask them if they've found themselves trying to manually merge files where multiple people were contributing, or if they've found themselves with files named HomeworkAssignment_FinalDraft-3-ReallyFinalThisTime-6.txt. If students have seen these problems, they'll naturally see the benefit of version control.

Present version control as a solution to the problems that they're already experiencing.

In other words, don't make it theoretical. Make the lesson practical and pertinent to what the students actually do.

Go through some example scenarios. Explain how they might use Git to solve the above problems, and focus on real actionable things they can do:


Here's how you'd set up a code repo so you and your team can edit files without breaking everything.
Here is the command you'd run if you wanted to upload your edits.
Here is the command you'd run to download changes from other people.
Here is how you'd resolve merge conflicts.


Even better: have students run through these scenarios live. Have them typing commands and pushing buttons instead of just listening to you. This should be information that they can actually use, not just theory that they'll forget as soon as they leave the classroom.

Don't spend an hour talking about theory. If students have never seen version control before, then they don't need to know how Git stores changes. They need to know how to setup a repo.

On the other hand, don't spend an hour telling them about all the different things Git can do. If you throw a hundred different commands at them, they'll remember zero of them.

Instead, introduce specific problems (that the students have already seen in their own coding), and show the solution to those problems. Have students work through those solutions and practice the commands right away.


  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?


Students should understand branches (bonus points for using branches to do pull requests and code reviews), but do you really need to get into this level of detail? Imagine students writing this down as you lectured. Would they really need to know this later, or is it just clutter?


  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?


Meh. This seems like trivia to me. Do I need to know any of the above to solve the problems I'm having?


  Merge conflicts happen; should I mention how to go about resolving those?


Yes, absolutely. Like Michael said, this is a very common problem that students will face, so they should definitely know how to handle this case.