This is what everybody that says they don't use version control does.

All they need to do is to compress those folders with zlib, and then they've reinvented git.

If you're just one person, you can work directly on master and just commit everything every time:

    git commit -am "I did some work"

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.

-- git add .

-- git commit -m "I did something"

-- git push

How???

On the other hand, finding the folder for last Wednesday and opening it up is easy.

Also, pushing your repo to Github / Gitlab / Bitbucket / (a thousand different free services) and then looking at the commit history visually is incredibly difficult.

Come on people, get a grip.

For a single-person, single-branch workflow, git is extremely easy. It gets really complicated when doing something more, until you stop seeing git as a VCS tool, but rather as a tool to manipulate the data structure used to do the VCS. But that's a completely different, unrelated topic to this thread.

Unless you don't use a GUI for browsing your file system, you really can't dismiss the GUI that comes with Git. It's easy to use the history browser to check out code from certain dates. And it even simplifies tagging commits so you can check out "release 3" instead of referring to a list of release dates.

1. Click folder in Windows Explorer

2. Press Ctrl+C

3. Press Ctrl+V

4. Press f2

5. Type new name

6. Press Return

Mac OS X:

1. Click folder in Finder

2. Press Cmd+D

3. Press Return

4. Type new name

5. Press Return

(No real idea about Linux, which I'm only confident with from a programming perspective.)

If nothing else, it's at least fewer keypresses.

It's does everything you would need to do manually do with copy paste (diff, merge, find old changes, comment changes, etc) but with much less effort (assuming you use a GUI).

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.)

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.

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've used git for so long and so deeply that it's ingrained in the way I think about code - I break things into atomic commits, and regularly traverse and edit the commits in the feature branch that I'm working on. That doesn't change when I'm working solo, nor do my commit message style rules. I find it very useful to be able to investigate the history of a piece of code, even as it moves across multiple files, and figure out what happened and why.

That said, when I'm working on a team I generally don't care how many concurrent branches are being worked on - it's not a problem at all if the threaded view is n levels deep. When I'm working alone I tend to have a linear (single threaded) history, with tags for each release or deploy.

This is something that I struggle with. And it sets me apart from the apparent majority of (younger) programmers.

At best, once I've baked something enough that I'm satisfied, I can go back and break up the work. But then what's the point?

From my perspective, the agile/scrum mindset (velocity!) leads to spamming the code base with poorly reasoned trivial changes, frequently just kicking the can down the road, happily accumulating technical debt like an accretion disk.

Alas. I think the youngsters are more correct. Code bases are now so short lived that anything more than the bare minimum is just wasted effort.

I miss the days of product development and burning CD-ROM gold masters and people at least tried to hammer nails straight.

I know, I know, get off my lawn and all that.

You're still using git for real even if you only ever have one branch.

  myproject.final.zip
  myproject.production.zip
  myproject.backup.zip
  myproject.backup2.zip
  myproject.shipped.zip

myproject.final3.zip

myproject.final_for_real.zip

Been there done that. I prefer git where it's all just meaningless hashes, or semver tags.

I meta love DF for it's primitive development practices too.

Guy decides to make a game with a block of stone and a chisel, development community calls him crazy and says games can't be made that way, but he keeps chiseling away.

In fact it's pretty well known that Dwarf Fortress has a horrible code base and it would be a huge project to bring it up to a good standard.

In this era of self-promotion some people actually can't recognize those things.

But I think its very obvious that he is a good programmer. His work is literally legendary.

It's unfortunate that people latched on and the "Notch is a bad coder" meme took off. I imagine the same is true with Tarn.

"His work", as in, the game he made. Game development is a multi-faceted beast. It is quite possible that while game design is awesome, technical implementation is a mess even if it reaches the goals.

I have heard DF being praised for having so many things to do, for being able to create wild stories, etc, but never for technical excellence.

DF is definitely an admirable and awe-inspiring project, regardless of the beauty of its innards

Genius is one percent inspiration and ninety-nine percent perspiration - Thomas Edison.

A friend of mine, years ago, took the "daring, revolutionary" step of convincing NASA management to embrace version control. I also know of a European consulting firm which made a lot of money swooping in and saving a major Euro bank's problems due to lack of version control.

But yeah, this is undoubtedly a factor in the games rather glacial development rate.

https://github.com/tareqak/df_raws_helper https://github.com/tareqak/df_raws

Configuration Management isn't just about keeping your source in source control software / server somewhere, it's also about the tools, dependencies, and other artefacts that you need to build and distribute the software.

How many people take great care for the version control system but forget everything else?

One of its big issues is performance. For an ascii game.

If anything, it is an example of how saying "Eh, screw it." can stall your progress

[0]http://www.bay12games.com/dwarves/