Learning git was like every other cool tech thing for me (including the fediverse). People explain it in such a convoluted way. It’s like they think you want to understand the deep theory of it before you get up and running!
Yes, git is more than just a “save box”, but really, new users should absolutely just think about it as a save box. Learn the fancy shit later.
Honestly this is me. At this point I really should know better but I dont, and every tuorial seems to be speaking a whole new language. Any tips for where to learn this?
It’s ridiculous isn’t it? You shouldn’t have to feel like you’re learning some cryptic new language to use version control software.
Just do a really simple work flow:
“Clone” the code repository from the internet onto your computer (“clone” = “copy”). You only do this once.
Edit code like normal
When you feel happy with some changes you’ve made, “commit” them (“commit” = “save”)
When you’ve committed a few changes, “push” them back to the original repository so your coworkers can see your changes (“push” = “publish”)
Repeat
There are a few good practices:
“Pull” often. I.e. update your local copy of the repository with your coworkers’ changes
Write an intelligible message with every commit so you and your coworkers can understand what you changed
If you’re going to take on a big project, make a “branch” and work there. A branch is like a copy within a copy of the repository so you don’t mess with code that’s already working. When you’re happy with a bunch of commits/pushes in a branch, you “merge” it back into the main repository.
Git was just released while I was in college, and I was in a group project that required us to use SVN. First job was a TFS shop. When git finally matured to the point that it couldn't be ignored anymore, life became much much more sane.
Subversion has some features git lacks or lacked for a very long time (I think it has most now). The biggest being able to easily clone and work with a subset of the repository. That's Subversion's entire thing! Don't misunderstand, I prefer git and think it is better.
Yeah, remember the giant merge conflicts I had to deal with because of our lack of experience with git. One really learns how useful it is to split stuff into files with git. Also the headache of line breaks and case-sensitive paths.
No horror stories to tell, though. We all got through our first git learning experience without any major accidents. Once we had to re-up the remote repository from a dev machine, that was it.
I've recently worked on a project that was using Plastic SCM for version control, and omg the QoL is so insane on that one. It's such a shame that Unity are greedy as fuck and tend to ruin everything they acquire, the licensing costs for Plastic are awful.
For example - I really low how it tracks what was merged from where, so merges aren't just a single commits, and if you for example pull something into a feature branch you are working on, and then merge the branch into master, all of the files that come from your branch are listed as changes in the commit, but files that were merged into your branch are marked as "merged from XXX".
Having PRs (code reviews) integrated into the client is also nice, since you can just link changes with change requests directly, and since it was made for Unity projects it also pretty nicely handles large files.
It's a shame that Unity acquired it, though. My last experience with their business model was when I was looking for a streamed remote play solution for a Unity game - which was exactly what Parsec offered as a free open source SDK for years. Until Unity bought them and close-sourced it (or rather - changed to "contact us for access to the SDK)), and when I contancted them for the SDK for our small student's game, they were willing to cooperate and give us an access - if we pay them 1 000 000USD for it. Which they had the balls to ask for even though I've specificly mentioned in the email that we are a bunch of students who work on a small game in our free time, which I find really baffling :D