6502.org

In the 80s when I wrote 6502 programs I kept the whole program in one file. Without any mentors, I learned everything from magazines, and the ones I had didn't discuss conditional assembly, macros or include files. The assembler manual did, but I didn't understand the concepts or how to use the features, so I ignored them.
This mode of development meant:

• I'd save my source to different filenames as a form of version control.
• I'd save versions of my code with test features on an off
• I had to put up with very long assembly times.

When I moved to 68000, the assembler package included a linker, allowing files to be individually assembled and linked separately. Again, I didn't understand what that meant, or how it could be used, so I ignored these features.

Nowadays, I:

• Make use of source control (git) for both applications and libraries.
• Keep constants and macro definitions in header files
• Use conditional assembly for feature switches and debug
• Use macros for code auto-generation and common multi-instruction patterns
• Separate libraries from applications. When I find myself copy/pasting a function from one project to another, I take time to study if the commonality can be factored out into a general utility function that can be used across projects. One implementation. One place to bug-fix.

My editor of choice is vim on a very spartan X Windows window manager with minimal decorations. I use vim in a very 1990s monochrome non-syntax vi mode. I've tried syntax highlighting, but it's not for me. I used a code-folding plug-in for a while. It reminded me of the folding editor I used when writing Occam code for the Inmos Transputer back in the early 90s, but it works by inserting comments into the code, and that didn't work in a team project environment as others didn't like what looked like clutter in the file.

Aw, I missed the tabs-vs-spaces war! :-) (I won't bore you with my opinions on that, but if you're thinking about it I encourage you to consider how your code is handled when not viewed in an editor. I read a lot of code in diff and git log --patch output.)

Emacs versus vi is the classic editor war. If you're not very skilled with an editor it probably doesn't matter which you use, or even if you use neither. (And you're also crippling yourself, but that's another topic.) The primary difference between the two is that vim has a more efficient typing interface (again, if you're skilled with it) and Emacs has much better programability (Vim programmability is a nightmare in comparison ) and rather more features. Some of the extra features and functionality may be of little value to you if you're a command-line power user and already have a good windowing system. (I have a heavily-customized set of Git commands, not to mention close to a thousand lines of other stuff in my .bashrc, already; porting all that to Emacs would be a huge project, and then that port wouldn't work on remote systems without Emacs. And who wants to start up Emacs just to do a git log <insert-lots-of-options-here>, anyway?) Using nested windowing systems, to the point of putting a terminal window in a Vim window in a tmate window in an X11 window, is oddly popular.

By the way, vim also offers folding. I've not used it in many, many years (basically, since I stopped programming in painfully verbose languages like Java), but now that I'm doing extensive documentation in Markdown text files I'm considering spending some time to learn how to use it again.
You might consider creating a few scripts to make this process easier. Instead of copying the folder, store a snapshot of it in a ZIP file. Then write something that tracks the relationships between the ZIP files (i.e., version Y is based on X with whatever changes) as a graph, lets you add a note to each explaining what the change is, lets you get diffs between versions, etc. Last, add some code that lets you automatically synchronize these sets of ZIP files so that you can simply say, "add to that other set of ZIPs (possibly on an exteranl drive or a remote machine) everything it doesn't have from my set here," or "fetch from that other set everything I don't have."

Of course, then you'll have rewritten the core of Git. :-)
A Git repo is just a bunch of files, exactly as your copied folders are. So there are no privacy issues in Git that do not exist in your current system. If you don't want to make your code public, don't upload your files or Git repo to a public server.
I wouldn't say that they're extremely hard to use, any more than object-oriented programming is extremely hard. With both there are (possibly radically unfamiliar) concepts one needs to learn, yeah, but lots of people learn the basics without too much difficulty. Git does suffer from a UI much worse than it needs to be that, very unfortunately, cleverly hides its easy-to-understand core.
I find Git invaluable for solo use. The two features I can no longer live without even when programming (or making any sorts of files, such as schematics or documentation) entirely solo are easy backups without requiring any sort of server software ("git push" to another directory, local or remote, is even easier than copying a folder) and easy arbitrary code checkpoints with attached descriptions. I have a half dozen very private Git repos that have never been (and, I hope will never be) seen by others; managing them without Git would add a significant amount of unnecessary work to my life.

Perhaps worth repeating from upthread: It's an important point, that using revision control, or source control, is a useful discipline even working on your own. Collaboration is another angle, and easy sharing of code online is another one again. They are independent - don't confuse 'git' with 'github' or for that matter 'svn' with 'sourceforge'. (There are a few others, too, such as gitlab.)

Actually, I use it because of it requires less discipline in certain areas. I would use checkpoints much less if I had to deal with copying individual files and dealing with (and keeping track of) naming of various versions of files, and that in turn would mean that I'd be less inclined to try out experimental or radical changes without more careful thought ahead of time, since it would be more work to roll back if the change doesn't seem to be working out so well.
Right. And also keep in mind that distributed version control systems are an entirely different animal from server-based VCSs. The former can be used just like files trees and archive files, often without a server at all, and "servers" can be added later in arbitrary ways. (You can actually just dump a Git repo—with a few minor format tweaks—in a directory served via HTTP and people can clone it using the HTTP URL. Obviously this is a "read-only" server.)