+1 for looking into a docker solution mate! I've come to accept GitHub for raw code storage as we use a similar system at work, but I've been recently looking into docker and other container orchestration to run things. A cluster of a pi or two can be a pretty great thing for running little containers :-)

many years ago I vowed to free myself from the bondage of failed host machines having one too many times been bitten by a croaked motherboard and then the hassle of reinstalling os, drivers, software, not to mention copying the data.  I have long since instead put my 'dev' machines in virtual machines.  Now, pretty much whenever I start a new project, I take a 'clean' image, make a copy, and install whatever stuff I want into it.  If I need to move the image to another machine or laptop, or if my desktop fails and needs to be replaced, I just copy a (very large) file, and I'm back running.
It's not absolutely perfect, but it satisfies well into the 90% of my needs.
Truth be told, in this day and age I should look into upgrading my process by doing a similar thing via Docker.

well, shoot... I thought I replied to this.

That's actually a pretty brilliant idea I'd never considered. Then even ten years down the line you've still got the same version of e.g. avr-gcc, knowing its oddities, pragmas, optimizations, and workarounds rather'n finding out new ones every time the project is revisited. Hmmm. 

I try to keep my code C89-compliant to avoid such things, but it's not really 100% realistic, since especially optimization and memory-space-access improves, but can also affect timings, etc. that one may not even be aware their code/component functionality/interaction relies on. [E.g. toggle a pin to strobe an external latch; an older version might use sbi/cbi, a newer version might setup values in internal registers, then use two sequential PORT writes. The former resulting in a strobe two clock-cycles long, the latter only one... which might be too fast for the external latch.] Seems no matter how hard one tries to avoid such things, there's always a new thing to break a previously-functional project. [Oh, when they switched the technique for accessing strings etc. in program-memory. A nice improvement, but a lot of code-rewriting!]

Virtual machines... whoda thunk?

Only thing is, pretty much all my code ties together, even across architectures [AVR, PIC32, openGL] with libraries and such... so I guess I could just do a single VM for all that, rather'n for each project. I tried the git thing for my projects and style... eugh, that was a big no-go. Can't begin to imagine how that could work for something with as many branches as, say, the Linux kernel; seems like a nighmare.

You almost have me sold on the VM project-environment... and then I remembered I just got forced into downgrading from a multi-core x86-64 with vm instructions to an ARMv7... :/ 

I guess I'm stuck with bowing to my mobo architecture for the time being.

Good to hear from yah, BTW!

actually, though, I was kinda thinking of a similar idea, cross-platform, even, for "fun" [rather'n projects]. Apparently DOSBOX can run Win3.1, and I've got a few Win3.1 games I like to play whenever I get a new mobo running. I think that "virtual machine" environment could be copied-over to each new/differing mobo [these days] and even run on an ARM ;)

When I say 'per project', sometimes that literally means per project, but it is more 'per build environment'.  I just mint out copies of the clean VM with dev tools already installed when I want a distinct VM for something, which might be a project, but often many related projects are in the same one.  For example, when I was doing the Omni stuff with you, that was in a VM I already had with some other projects that were Z-80 related, rather than clone a separate machine.
For me, the ability to 'back up' the computer -- data and 'hardware' -- as a single file is what makes me like it.

If you're on ARM, you may be out of luck.  The modern VMs get performance by running the code in the VM on the host processor (and doing shenanigans for the privileged code in the VM), so they generally don't work cross-architecture.  DOSBox gets away with it because the machines it is emulating were so very slow back in the day, that there are cycles to spare.  Even with the shenanigans, it can be hard to get performance from the VM.  If you're playing modern games, you might give it up.  Also, Ubuntu's 'Unity' window manager is intolerable.  For this reason I use Ubuntu Mate in a VM, which spins like a top.

Of the VMs, I personally use VMWare, which I find to be most performant on PC.  But it is non-free.  Virtual Box is a direct competitor, and is free.  But I find it a bit slower.  For many things, the speed is not an issue.  Editing code, compiling, running debuggers -- who cares if it is slower. (don't tell the apple fanboys that)

Lastly, you might check out Docker, as I mentioned.  It's a more contemporary alternative that is functionally similar to VM's, but actually is more like souped-up chroot jails.  The gist is that you specify a config file -- a 'recipe' -- that specifies all the stuff that is to be installed in the Docker 'container'.  This would be all your dev tools and whatnot.  Then you use them inside your 'container', but they are isolated from your host system, and you can save off the disk image much like as with a VM image.  This is much smaller than a VM, which has a full OS image.  By using 'recipes' specifying what software you are installing, ostensibly it would pick the one that is built for the host machine's architecture, thereby getting by your x64/ARM issue.  However it's much more used in the Linuxian world than Windowsian.  I haven't dug into it yet because there's a conflict at a kernel level in what it requires on Windows relative to VMWare's assumptions, and I have so much invested into my VMWare images that I've put off futzing with it.  But none of that matters if your host machine is Linux.