Version Control - Why is it better than simply copying?

So I am a simple dev that has only made 1 small game for iOS and Android. With my projects and tutorials I have gotten away with simply making copies of my entire project folder and adding notes about each folder/build in a spreadsheet. This system has saved me a couple of times when things went bad, and loading the previous build/folder saved me a lot of time.

What benefits does a version control program like SourceTree give me, and why should I bother spending the time to learn it? Or is this one of those "you will need it the more complex and larger your projects become" type of things?

 

Version control systems record changes to files over time allowing you to recall specific versions later. That's almost literally the line out of the About Version Control page on Git's website.

 

So it sounds like they are more like a restore program in the sense that they only copy things that were changed as opposed to how I am currently making a copy of the entire project folder and with integrated note taking as opposed to having notes in Excel.

 

Version control additionally allows you to view changes between two or more versions of a file, track who is making changes and to which files, review past changes and comments left on those changes, maintain multiple branches of your code, and act as yet another backup.

Yes, you absolutely could do all of this manually... and it would be a colossal waste of your time.

 

By the way that list of advantages and more are mentioned on a Stack Overflow entry. You may want to read it.

http://stackoverflow.com/questions/1408450/why-should-i-use-version-control

 

Can you recommend a flatfile version control system? That would be a more comfortable transition for me than straight to cloud-centric-over-a-network version control.

 

Are you asking for a version control system that can store files locally?

 

It can also help you avoid stupid mistakes, like this one that happened when I was working on Sara the Shieldmage, but which got caught on camera. The fail in question is realized at around 50:00 on the head.

All I had to do was back out certain of my changes, and do a small amount of rework, to recover during a livestream.

TL;DR - Version Control can save your behind in a pinch. Copy/Paste doesn't do that. Dropbox sure as hell doesn't do that. If you want to be able to recover from those Oh Crap moments, you need some type of version control.

 

Yes Local servers are also acceptable, but flatfile (even multiple files) would be best.

 

Git. You create your repository locally. If you want remote saving - something I recommend in the event of your hard drive melting, changing devices, or a Space T-Rex taking a crap on the place you develop at - you have the option, but it's far from mandatory.

Git is a distributed system - a network of developers using Git all have their own local repository. This also facilitates cool options like forking off to try different things, concurrently with the 'trunk' of the project. It's also easy to merge forks into the trunk to 'take' a certain set of changes. It's something I rarely do, but if/when I get to a point where I need to do A/B testing, I can just create two forks, do both approaches, make both builds, show both builds, get feedback on both builds, then go with whatever works better.

 

You could give this a try and see if it's still valid.

http://invalidlogic.com/2006/12/06/using-subversion-without-a-subversion-server/

 

TY for the link. Yeah manual is how I am doing it right now, but

That was a great read. Time to learn a new tool. TY!

 

Oh wow, I've used that one before! It was to download files directly from rkeene's files whilst working for sandswept. Nice, I forgot about that.

@Flybye I recommend tortoise svn, it's pretty easy to use and my experience was using it for a unity project!

I develop mostly on mac right now so it isn't an option, but I will take this and @Asvarduil 's words and google around. If local-git is the best option then so be it. If writing my own system is the best option then I will do that as well

I've been interested in cli tools that have 'watch' options, this could be my chance to make one.

 

Thx! I will start looking into it as well.

 

sometimes you break your code and you're not sure how.

version control will be able to tell you which lines you changed so you can see.

 

I use GitHub Desktop. The workflow is simpler then source tree. My remote is on BitBucket.

As to why version control, here are a few thoughts.

• Only individual changes are tracked. Making it quicker then a full backup, even for a small project
• Change history is kept and can be viewed at any time
• Collaboration becomes trivial
• You can access your project anywhere on any device. You can even browse source on a mobile
• You can create branches to test new features without destroying your main build. Switching between branches is trivial.

Version control is also pretty trivial to learn. Set it up today. You won't look back.

 

Not having version control is like taking all the money out of your bank account and putting it into your wallet.

Just hope you don't lose it.

 

Another benefit is branching. Let's use a very simple example (you'd probably want to get a little deeper, but for a single developer this would be sufficient):

Main- Clean copy of your source code, this I where you start - this is your Trunk
--- Release - This is where you would merge to each time you do a release
------ Hotfixes - A branch that allows you to do hotfixes on individual releases
--- Development - This is where you do your development.

So you create a Main which is your project. Then you create a branch called Development and a branch called Release. Do all of your work in development. However you do your iterations, you can merge back to Main whenever you have a good working piece of code or feature. In a more complex scenario you would have Test and possibly QA/UAT branches as well that would sit between Development and Main... but you are just one developer.

Once you've gotten a complete version, ready to push out, you merge from Main down to Release. At this point it should already be heavily tested and this is what you're publishing. The Release branch becomes a checkpoint for your version. Alternately you can create a separate Release branch for each version, but I like to keep it simple and use Tags/Labels for my versions instead. This merge becomes Version 1.0.0.

Now you continue working on new features and cool stuff in Development. You're half way through crazy feature X when a customer of your current release says "Holy crap, Feature B is broken". No worries, you create a Hotfix branch off of Release. You could create multiple Hotfix branches, or again... as a single developer just use one. You do your hotfix, then you merge it up to Release once it's working. Now this merge to release gets a new Label/Tag and becomes Version 1.0.1.

Merge Release to Main and merge Main back to Development. There... now you pushed a hotfix, AND incorporated your hotfix into your current development cycle without having to do anything with Feature X that you were midway through developing.

Now you finish Feature X so you test it and merge it up to Main. Finalize your testing and then:
Merge Main to Release... now you have Version 1.1.0.

Using source control and following a structure like this allows you to maintain and patch a product while simultaneously working on new features and without those updates interfering with each other. You continue this cycle as long as you want. And you can use a different branching strategy. You may go further and create a Version1 branch off of Development. And when Version1 is done, you may branch to Version2.

This also allows easy rollbacks. Say you release version 1.1.0 and it has a serious flaw that is going to take a lot of time to fix. Since you tagged your releases, you can actually pull a specific version from source control, meaning you can pull version 1.0.1 and revert back to it very quickly.

Shelfsets are also useful (like temporarily checking in your code in a sandbox so you can use it as a backup, or pull it on another computer and continue working on it). I like to use shelfsets for unfinished code. I don't want to commit anything to source control that's in a broken / unfinished state, so I'll use a shelfset to hold those changes in source control until I'm done with them, then I'll commit them and delete the shelfset.

 

That metaphor works out great for banks who have bailouts for their version control

 

Downloaded and am playing with both now.

 

I use Perforce for my team's version control. From a straight features point of view, it's actually pretty excellent. It manages the files in depots and uses local workspaces to keep things neat and in order. They also have a fancy new UI version for those who are command prompt impaired. The major downside is that it has one of the steepest learning curves of any tool I've ever used. Mostly due to the fact that there is very little documentation and any documentation there is must be found by rummaging through directories.

On version control in general, yea it's very important. Not only from a backup point of view, but from a collaboration one as well. Knowing that a file is actively being worked on prevents you from overwriting the changes someone has just made, which can get really frustrating depending on your workflow.

 

As an aside, I use Visual Studio Online. It doesn't have direct Unity integration (@Aurore hint hint), so there is a little manual work to making sure your files get added properly, but I love the features. I use the TFS integration for it, but you can use it as a Git repository as well, it's free for up to 5 users, and storage is unlimited.

 

That's probably the best option. My experience with git is too limited to compare it to tortoise. The 1 thing I do know is that tortoise is aptly named... or that the keene family has terri-bad internets.

 

Ok. I have decided on SourceTree for now.

Just playing around with 3 text files, I find ST to be the easiest for me at the moment. I really can't believe it is as simple as double clicking on a time stamp to make that one the head and that is that. I saw my text files being removed and added like magic.

Github destop was giving me odd errors when reverting, and quickly looking online people were giving out command line stuff to fix it. Forget that. I took a week vacay from my non-dev job to cram my dev stuff, and I figured out SourceTree pretty quick, and it does the job. But I will play around with the others as time goes by.

 

SourceTree is more powerful then GitHub Desktop. If you have SourceTree figured, then there is no point playing with GitHub Desktop. I mainly recommend it because its uber simple.

 

Tell me a story about source tree.

 

Git also has a Tortoise client.

 

I use TortoiseGit - it's actually pretty good, and insulates you from the command line stuff very nicely.

 

Why bother saving at all? Your computer shouldn't turn off randomly on its own, if you know what you're doing. Yeehaw!

 

And who needs crash dumps. I put 32 GB of ram in my desktop and turned off the page file completely.

 

I installed a flux capacitor in mine and hooked it up to the network card. As a result, my computer stores information in itself in the past, present and future, including some alternate timelines. I'm pretty sure some of my last game is backed up in Julius Caesar.

 

I also delete my paging file. And restore points. Both are unnecessary.

 

This whole thread asks the wrong question - it's essentially asking if version control is backup. It can be. What it's really powerful for though is collaboration. You just can't effectively collaborate without version control projects. Version control isn't just text. You can have perforce keep the project in sync from directly inside of Unity across lots of developers. Some guys are doing art. Some sound. Some are level builders. Then there's programmers.

Version control doesn't sound too exciting until you bite on projects with meat.

 

Version control is a lie. All control is an illusion. Free Bieber. Fight the man.

#legalizeranchdressing

 

I don't know I agree with that interpretation. While there's some overlap between the two, the OP's description is pretty much exactly manual version control...

... especially the part about keeping notes about each copy in a spreadsheet. It's a manually maintained, documented history of changes to the project.

 

My impression of the OP was that he's a solo developer.