They take backups, name each folder based on the date, and what feature that was just completed (or just about to be started) that prompted the backup. I bet you a pound.
This is what everybody that says they don't use version control does.
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"
-- 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).
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.
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.)
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.
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.