Version Control & Git

Basically: Your backup system for when you fuck shit up, or the world tries to fuck it up for you. No matter if you spend the last 3 hours breaking everything in your project, the software you're using had a bug and corrupted your data, or your hard drive decided it has worked long enough - version control is there for the rescue.

You can think of it as a way to save your data, but instead of only saving the current version of it, it saves all changes you ever made, so you revert, review, or redo any of your previous actions.

One of the most popular solutions for this is GitHub, but there are many other ways to do it, and the setup should only take around 15 minutes, depending on the way you go about it.

When using version control, you will work with the following concepts. Some solutions call them differently, but most work in a similar fashion.

The place where your projects history is stored. Most of the time, each project has one repository, in which its history is stored.

A commit is a package of changes (like adding files, editing them, or deleting them). They can be small, or big, and should always have a name describing what they changed.

A branch is like a separate line of work in your project. This could be a "beta-branch", an "experimental-new-feature" branch, or a "legacy-version" branch. Most beginners really only need one branch, but in bigger projects, it can be nice to work on big projects separately, and then merge them later.

Merging means combining to branches. For example, in a team, you might have spend the past week working on a dialogue system, while someone else worked on the player controller. For this, you created two branches, so you don't have to worry about the experimental code of each other while working on your feature.
When you're both done though, you merge your branches, combining all the changes into one branch, and while doing so, everything is compatible and does not explode upon meeting for the first time.

Pushing and pulling is just uploading/downloading the commits you made on your device, to the Remote. The central instance of your repository, so that its save and others can pull them. If in a team, before you start working, you should always pull, to make sure your on the latest version of the project.

The remote is the central online copy of your repository. Basically the cloud, were you push all your changes to when you commit them.

Sometimes, two people work on the same file, and then both try to push their changes to the remote. Well. Git does not really know which changes to keep, so now we have a conflict. Most platforms make the solving easy though, and just let you select and edit which parts of which commit you want to keep.

There are many options to choose from when it comes to version control.
So what to actually use? Well, it depends on what you want to do.

For most development, like web-dev, python, or java, I'd recommend using Github.com.
It's the easiest

For game-developers in Unity, I would recommend using Unity Version Control. It's easy to setup and supports file-locking. It also is integrated right into Unity 🎉

https://github.com/
One of the most popular solutions for version control and is easy to use with GitHub-Desktop. Free in most cases (see here).

If you want your files to stay were you want them, you can also host git yourself. On your pc, on a local server, or on a webserver you host/rent. Keep in mind though, that this is a bit more involved, and when hosting locally, the files are still all stored in one place, which increases the risk of data-loss in case of e.g. a fire.

Unity Version Control is Unity Engines own solution to version control, supporting file locking and working working with branches, as well as a simpler approach.

-> Anchorpoint.app
While I have not worked with this yet, I'll try it out soon, and from it's looks, it seems like an easy to use solution, and in addition to just the version control, also includes an asset manager. One point to note is, that file locking is only supported in their paid plans, and as far as I understand, you still need a GitHub account were you actually host your files.

-> Perforce P4 (Helix Core)
A great solution and I think the common path for projects in Unreal Engine. It does require some setup and can be harder to get into then the other solutions though, so keep that in mind and do some research before you jump right in.