How about just making branches and merging? Why do I need to explain that to an employee? If they can't do with git very basic things it's because they're not willing to read.
What you need to shepherd them toward is not the commands to run to branch and merge, but the why. Why are branches useful? When should you merge? What do you do if there are conflicts? Most of this stuff isn't book material. It's what senior developers should be teaching junior developers.
Although the original commenter referred to junior people, I'm often having to explain these things to those who are not - sometimes to people with more experience than I have (e.g. 15-20 years).
Besides, there are plenty of online resources as well as books on the purpose of branches, and its benefits. Some of these have been around since before Git existed. I don't have a problem explaining the why, and pointing them to resources. It's the inevitable "OK, but how do I do that with Git?"
Extending it a bit: I often work with people who will never read a manual. They'll want to find a quick SO answer, or a short tutorial for everything. But once in a while, you need to read the man page, or the official docs.
Ok you convinced me that you're approaching this in a reasonable way. I also eventually check out from helping people who I become convinced are unwilling to help themselves.
