actually, a good way to think of it is releases. even with git, i keep a copy of each project release, that itself is not stored in git.
I haven’t used cli git since uni. GUI is better for basically everything except for a few rare and advanced commands.
Jeremy Howard (of Fastai fame) has a good analogy that we do not make people sit in a classroom for a semester to learn all of the theory of baseball. Instead, we give them a bat and a ball, and layer on the instructions of how the game works. You can get a good approximation of the game with just a couple minutes of instruction and refine the understanding from there.
i don't expect a fresh graduate to be a skilled git user but if the nature of development at work is substantially different from what the student learned at school, then they will have a much harder time adjusting.
they should at least be familiar with all the concepts that they will encounter in a junior job and not be faced with having to relearn a completely different development process.
The hard thing about source control is not the how — using the git CLI is only slightly more complicated than copying a folder. Git turns that into a very straightforward directed graph, and the CLI gives you a few commands to move around the graph, sprinkling some more edges and nodes wherever you like. It takes about an afternoon to figure out once you're onboard with the why.
The why of source control is the thing — and our industry is already full of people who don't understand it. That's how we get people who treat git as a "save" mechanism to be invoked whenever it's been a while since the last commit, or branches with one sloppy commit message after another [1], or entire repos that are just spaghettified carelessly-merged hairballs of commits.
Mastering the why of source control means learning when to cut a commit, what shape that commit should be, and why that is.
And I think that's more my objection to the teaching approach outlined here — without any other context, it reads to me like it's not quite focusing on the right things. At worst, it's inducting the student into the industry-standard cargo-cult approach to source control. [2] If the why isn't learned, then it doesn't really matter whether the specific motion is copying folders or typing in git CLI commands.
Ideally I think source-control techniques could be introduced right when they're going to be interesting or fun — when it's time to build something together with someone else. Then that set of lessons could start by copying folders and eventually building up to git — and each lesson could show how good, disciplined use of source control concretely improves the collaboration process.
[1]: https://tbaggery.com/2008/04/19/a-note-about-git-commit-mess...
happy path
You can't do everything at once and git is counter-productive on day one, and the most important thing was they find programming remotely interesting at all.
The next most important thing is always working on a new copy.
How exactly you make those new copies barely matters at all compared to just having them at all.
Using something arcane and unforgiving and inscrutable and complex like git to accomplish those copies is way way down on the list.
The new student is barely interested in the actual coding to make a game if you're lucky. They would rather mow lawns than learn administriva like git.
It could even be argued as irresponsible to hand git to babies and expect everything to be fine. Just because we all have about 5 git commands we use 99.9% of the time, and have no problem 99% of the time because we learned how to "hold it right" and just always carefully do things in the right order, does not mean git can actually be made safe and simple. Those 5 or so commands aren't actually enough.