Version control personally and simply?

Question

Requirement

1. make history for web text/code source files.
2. login-worker is only me, i.e personal usage.
3. automatically save history for each updated files(no require at once but at least once per week)
4. It must be a simple way to start and work.
5. I have 3 work places so need to do async files.
6. (not must but hopefully for future working environment) Any other non-engineer can also understand the location of history file and can see it easily.

Current way: I made history folder the day, download files in there for edit, copy files when I edit/creat new one.

Advantage of the current way: Very quick and simple, no need to do additional task to make history

Disadvantage of the current way: Messy. Whenever day I work, I create a new history folder to keep downloaded files, so that it is messy in Finder(or windows explore). Also, I don't have a way to Doing Async files for sure with in other places.

I tested to use GIT before, I had Thought GIT automatically save files I edit and save with a editor, but that was not the case. Also GIT is too complicated to use/start. If you recommend GIT, you need to show me ways to deal with the problem I had, for instance, simple GIT GUI with limited options without merging/project/branch etc because of personal usage for maintaining just one website.

Do you know any way to do version control personally and simply?

Thanks.

Answer 1

Suppose you entered <form ...> in your HTML—without the closing tag—and saved the file; do you really think the commit created by our imaginary VCS picked up that file's update event would have any sense?

What I mean, is that as with writing programs¹, the history of source code changes are there for humans to read, and for that matter, a good history graph should really read like a prose: each commit should be atomic in the sense it comprises one (small) but internally integral feature or fixes a bug, and had to be properly annotated so that the intent of the change captured by that commit is clear.

What you want instead is just some dumb stream of changes purely for backup purposes.

Well, if you're fully aware of the repercussions (the most glaring one is that the generated history is completely useless for doing development on the project and can only be used for rollbacks in case of "oopsies"), there are two ways to go:

• Some IDEs (namely, Eclipse) save a backup copy of each file they manage on each save—thus providing your with such a rollback functionality w/o using any VCS.
• Script around any VCS you like: say, on Linux, you start something like inotifywait telling it to watch your project's root directory, recurvively, for write events on files, read whatever the tool prints to its stdout when these events happen, and for each event, call to your VCS of choice to record a new commit with these changes.

---

¹ «Programs must be written for people to read, and only incidentally for machines to execute.» — Abelson & Sussman, "Structure and Interpretation of Computer Programs", preface to the first edition.

Answer 2

I strongly suggest you to have a deeper look at git.

It may looks difficult at the beginning, but you should spend some time learning it, that's all. All the problems above could be easily solved if you spend some time to learn the basics. There is also a nice "tutorial" on github on how to use git, no need to install anything: https://try.github.io/levels/1/challenges/1.