Unity 2019 reuined my game.

It took forever when I was still doing it (eventually I just set up an automated process for git instead) because Unity projects are full of loads of small files, which are kind of a nightmare when dealing with in volume. At this point though, even for local solutions, there's no reason not to use some form of version control.

 

I get how doing the backup thing may seem easier on the surface, if you haven't used version control before, but it really isn't, especially when you need to back out or revert something. Pulling one (or a few) files out of an archive can be messy and super slow. If you are creating multiple archives, simply finding the changes is going to be a pain. If you are using it as more of backup than version control and replacing your archives, finding an old change may not be an option. Backing up is, as said by others, better than nothing, but using actual VCS is more efficient, robust and a practical skill set. There is literally no reason not to do it on any project that are planning on putting more than a few hours into.

 

I wholeheartedly believe in version control. Don't get me wrong. But I think the "make a flat backup, try upgrading the major tool system, experiment a bit including fixing quick errors, and if it's gonna be hell to accept the upgraded major tool system, just go back to the backup" approach is a fine approach. In fact, if a second machine or a second user account on the same machine is available, I would use that as my trial area. I feel there's not enough good reasons to risk polluting the original version control repo with a bunch of little migration experimental changes.

But in any case, do not upgrade major tools on your only copy of a project. Or as they said in the 80s, "always mount a scratch monkey."

 

Or better yet just make a copy of the project folder, delete the library cache in the copy, and open it in the new release you want to try out. Worst case if anything goes wrong you're only out the time to create the cache for the new version, but if you tried it on your working copy you'd be out the time to make the cache for the new version and the old one.

 

If you know what you're doing there is zero risk of polluting anything.

If you're using branches, then just make a branch and only commit new version stuff to that. If you decide not to carry on, stop using that branch... and that's it.

If you're not using branching (which I think is fair enough in plenty of circumstances, particularly for newbies) then simply don't push any commits back to the repo until you're happy with that new version. Locally, you can still commit / revert / whatever as much as you like, and it will do nothing to the contents of your repo.

Indeed.

For me, doing a commit and push typically takes in the vicinity of 30 seconds, and that includes writing a comment and double-checking the contents of the file list. That logs my work locally and pushes it to a remote server (thus doubling as a remote backup) in less than the duration that most computers will spend just locating files to put in the archive.

If I ever have to go back and get something from an old version then the productivity boost of version control is even bigger. I can right click on any text-based file and pull up a log of all changes to it, ever, by anyone. If I want to go back to an old version I pick one from the list and click a button. If I just want to look at its contents I double click it and it pops up in an editor with the differences highlighted. I can also easily see what other files were changed at the same time, and the changes made in those. And through all of that I don't have to navigate through archives or find files or extract anything.

Also, because version control only saves the changes it usually takes up very little disk space. Archives re-compress the whole project every time you make one. Version control identifies only what you've changed, and saves (with compression) just that. My entire version control history for a project is usually less than the size of the project itself.

Working locally you get all of that except for the remote backup. The tools are free.

 

My favorite advantage is things that you don't commit. (Or at least don't commit to the main branch). You can have a lot of stuff in a half done, broken state, and yet still have a project that will compile and release.

 

I sometimes use it to revert everything but the actual stuff i'm interested to commit. I use this all the time for code, remove noise changes like blank rows etc, its very nice to look at a git commit that actually only consist of lines that have changed. Most devs dont care, I always give my developers a hard time at work if they commit noise. Anyway, some times I extend this to scene files etc. For example, I ony want to change the rotation of a transform in the commmit but something else have changed too my mistake.

Btw, never refactor and commit new domain code in the same commit. Make two commits

 

@angrypenguin Have already touched it, but use branches, since git is distrubuted its super easy. You can even create a branch mid through a story and move to that branch before committing. You can even kit bash a custom branch by cherry picking commits from several branches. I use this sometimes when I want to let our testers test something in beta (usallyt a POC that I want feedback on).

 

I usually wait until I've made some major change, like refactor or rewrite of a large script, then just RAR up the whole project file (although, the library and stuff doesn't need to go usually, it could just be the assets folder).

Then I'll distract myself with some other work a while, and if the project isn't huge (mobile projects of mine don't usually end up over a couple gigs) it only takes a good 10 minutes or so, and finally I upload usually to at least one cloud service for my own sanity, in case I drop my laptop bag and destroy my external and my solid state in my laptop through some gifted moment of drunken-ness or something

Oh and another thing, is if unity is open while you do it, winRar complains about the unity lock file, but its safe to ignore it and just let it go through without including the locked files.

And for the record I've also used the source control stuff before, and yeah it is solid, and really awesome for comparing code when you have suddenly broken something that seemed to work fine before. I just don't think it is necessary if your a solo act most of the time...

 

The only folders you need to backup are /Assets/, /Packages/, and /ProjectSettings/.

If you have a total loss, you can still recover completely by opening a project with these folders in it. You don't need Library, unity just rebuilds it when you open a project that doesn't have it.

Collaborate is hella easy too for super basic versioning. Just click the button and everything is backed up.

 

Windows backs up my more valuable content every day; I cannot say how long it takes saving one project. Doing it manually take the time needed according to the size of the project...

 

Whoa, so windows does that automatically now? ....Scary... lol

 

If you tell it, yes.

 

The thing is, some kids respond to wise counsel and others respond to a bit of ridicule, and the wise counsel ones are usually those who will never obnoxiously attack as the entire world is wrong first. So you need to tear down the wall, then when the ego is sufficiently dented, apply wisdom with the subject willing to listen.

Pretty sure OP knows very, very well based on history of posting/forum account age - and just needs this set back to know that the problem is really between chair and keyboard, and the OP can evolve very well from this.

TLDR:

Basically everyone's piled in on this and I'm pretty sure most of the people (gently) piling in have a history of helping beginners, so this speaks volumes.

Offtopic now and OP didn't even post in the correct forum section either (clearly that didn't matter) so locked.