To jump on the wagon here - at its core git is just compressed snapshots.

Having to 'unfuck your branch' is a result of doing more than just storing compressed snapshots.

This is probably because all the training material and tutorials assume people want to do more than just snapshots, so as you follow along when getting set up it's easy to get into those kinds of situations.

As others have said, doing the compressed snapshot workflow is as easy as adding everything to a git repository, and committing it every time you want to make a snapshot.

The biggest hurdle is having each snapshot 'replace' the current one if you want to go back and look at it, but that's not a hard thing to adjust to for the value you get by using git's machinery for the snapshot workflow:

- fast and efficient remote backups

- greater compression (by using a shared object store for all snapshots)

- easy comparison of different snapshots

- bisection of snapshots to identify when a bug was introduced (including ability to easily automate running tests while bisecting)

- ability to change workflow in the future as needs change, in particular adding in remote collaborators, without having to change versioning system/workflow (well not too much of the workflow)

- rich ecosystem to easily publish source if desired at some point

- and lots more!

Many of these things are possible when you have a list of compressed archives of your source folder, but git really does make it much easier and you don't need to go all in on complex workflows to take advantage of it.

There is a learning curve, true, but it definitely pays off once you are comfortable enough with the (admittedly bad) UI. Even for 1-2 person teams.

If there's one of you, whatever, it's your problem.

If thre's two of you, I might be so bold as to suggest it would be worth giving SVN a try. All the usual handy version control system stuff that makes collaboration easier, but the mental model is simpler than git (with all the things you can imagine that might imply), and you've got a handy escape hatch, in the shape of svn lock, for non-mergeable binary files. Great for PSD files and so on.

(Another thing about SVN that's different from git: working copy disk usage is proportional to size of HEAD, not size of repo. You can reasonably use it for distributing binary builds to non-programmer team members, for example.)

Trying to learn git was a humbling experience.

Everything seems so simple and then suddenly you accidentally deleted all your local changes and have a bunch of similar but not identical branches. You get a message saying your head is detached and that feels right. At least your working tree is clean, you'd hate to have a dirty working tree.

You have a pressing need to learn merge but that launches its own fun minigame:

https://stackoverflow.blog/2017/05/23/stack-overflow-helping...

It's so popular and well documented that every time you get confused it feels like a personal failure.

The promise of git is phenomenal, and I know a lot of people realize that by mastering it. I just wish I had figured out a way to learn it more iteratively. It felt like there were a bunch of frontloaded concepts you need to master to get yourself back out of trouble. And if you ask for help from someone who doesn't include whatever you messed up in their normal workflow, even if they've used git for years they might not have any idea.

I have to say that I disagree with you. When I've worked on projects by myself, or perhaps one other developer, I've found git to be much easier to use than making manual backup-folders. There isn't really any need to use that many branches when you're only two developers, so most of the time you're just going to be using git commit, pull and push. It takes about as much time as making backups, and the ability to see exactly which lines where changed in each commit can be invaluable at times.

The ease with which you can review how things have changed in a large code base (one written even by just one person) is invaluable. Not hard to use and the upsides - being able to diff different commits - is really something that shouldn't be taken lightly.

> when you're just one or two dev

Version control has nothing to do with the number of developers, it's a tool used to snapshot code, allowing easy tracking, reversal, and plain old "I'll finish this later". I couldn't imagine trying to develop without being able to make a branch, try something out, jump back and fourth between features, and then merging everything together later.

I can't stand the command line tool, but a nice GUI like Sourcetree or TortoiseSVN makes juggling very nice.

I'm sorry but if you've been writing one of the most complex and elaborate video games in human history, you can figure git out, probably faster than it took Linus to write it (a weekend).