We were introduced to version control in our first year. The only problem was that till we started managing large code bases, most people found it very difficult to understand why we used Git in the first place.
Yes! Git is not merely version control but a specialized sort of version control. I've run into the opposite problem, when I've tried to use Git for projects that weren't source code.
Without thinking about it, just by reflex, I'd create a project directory for a new project: Web pages that were almost entirely English text, or a Photoshop project, or an e-book project...and init my git to track it and set up my server to push it to.
Before long, usually while trying to come up with a good commit message, I'd wake up and ask myself, "Wait, why am I tracking this? Am I just assuming it's the responsible, proper thing to do?"
It's not enough that the project be something that iteratively improves. Git's usefulness comes mainly from text data with extremely demanding constraints (hard to get it to work, easy to break, harder to repair than to start again, working/broken is not just a matter of taste), especially when you have multiple contributors, each of whom is more likely to break something than to fix it.
If you have non-text projects (ex: photo editing) or text that can usually be "fixed" by just pushing forward rather than starting again, Git still has benefits, but they may not be worth the costs.
You don't really see the value of Git unless you're writing code that you're a little scared to write.
I have to say I don't agree. I find git useful every time I do work that is even just a bit exploratory - which is almost all of it. E.g. doing a mockup in Inkscape - I'll commit, then create a new branch and try out some idea. If I'm not satisfied, I'll just checkout master and keep working on the previous version.
In fact, I think this is a common behavior; almost every PC I've seen has a poor man's version control implemented by the user by copying the file and renaming it (e.g. Report_1.doc, Report_2.doc, Report_2_valid.doc, etc), despite none of them being programmers or working with code.
But that's my point. I'm not saying that other things don't need version control at all but that many don't need the specialized, heavyweight version control features provided by Git. For many things that need version control (I'm not saying they don't), the lightweight "poor man's version control" of saving named copies is fine, so it will seem puzzling to someone doing only that kind of work why anyone would go to the trouble of learning something as complex as Git when a much easier solution is available.
It's when doing a specialized kind of work with more demanding constraints that you see the benefits that justify the cost of learning and using Git. If you never do that specialized work, the specialized VC of Git might not be worth it. "Poor man's" VC might make more sense.
Git works really well when you are editing Latex documents in groups. The merge features usually work pretty well, even if people have been changing the same document at the same time. You can find and check what other people have been doing. You can track updates. There is a central repository. It tracks embedded images too. In total, I would keep doing it, but the group in question is technical and can use basic git without problems.
edit: And you can undo when you find you need something again you deleted, which happens once in a while too.
I couldn't get my team mates to use it, but I did on my end, and it was a godsend. Other teams were merging stuff by hand and losing hours (in total) in the process.
Doing computer science rather than software engineering, I didn't have many. Most group assignments involved us sitting there together at a computer basically doing peer programming.
I've had multiple rising seniors as interns from top-tier universities who knew nothing about git. In one memorable conversation over lunch with one, I asked him how he got by without git; he used google sheets with classmates, and they also had shared a dropbox and only one person could work on it at a time. At first, I was dumbfounded that they had no instruction about it, but I realized its so dependant on your university and your coursework.
Agreed! Version control is not a natural concept that a beginning student would immediately think of. It’s also helping that a beginning student’s programming assignments are typically simple and short enough that doing without VC is tolerable.
They are also typically working alone (or are suppsoed to be!) in the early classes. Team projects tend to come later.
If you're working by yourself on the sorts of programs that are in introductory classes, you don't loose a lot without VC and it greatly simplifies things and lets students focus on the actual exercises/assignments.
Git would be horrendous overkill for a freshman programming class and it has so many footgun possibilities that the TAs would be going nuts helping students recover from various disasters.
