Version control is a way of checkpointing your code in a certain state (usually a compilable, but not perfect, state) that means that if you royally screw something up you can easily revert to your last checkpoint that was working and try again without having to individually undo every little change you have made.
A bit of history: the first one was rcs (revision control system) which almost everybody has stopped using (thank goodness), then CVS (concurrent? version system) which did everything basically wrong but was easy to use so a few people sadly still use it today, then SVN (Source Version or something) which did everything basically the opposite of how CVS had done it, and made branching from somebody else's code a lot easier, but made merging somebody else's code a nightmare.
After that, people started looking to what is now called distributed version control, which is where you can have multiple people working on multiple projects, and they can each make their own edits to the same files without continuously updating from the other persons version of that file, and then you can merge all of the different disparate versions back into a mondo version of the file.
This is usually used to have one person/team fix bugs, another person/team add features, and a third/person team experiment with new features.
Question: Why they didn't do that in the first palce?
This is talking back like 30-40 years, before the internet, i mean, they had barely moved from using punchcards to being able to edit their source code with a computer (gasp!) so having multiple people work on the same thing was just a distant dream for them and that is also why the internet is so fucking awesome, and why old people have such a difficult time with it
DVCS's (Distributed Version Control Systems) that are currently in use are some Microsoft one that nobody cares about but is integrated into Visual Studio so people end up using it, Mercurial (typically abbreviated hg), Bazaar (typically abbreviated bzr) which is put out by Canonical, the company behind Ubuntu, and Git, which was created specifically to manage the Linux kernel
Git was created because Linux devs were using some proprietary software to work on the kernel, but the license stated that it was free for any Linux dev so long as nobody tried to reverse engineer it. well, eventually somebody publically started to reverse engineer it, the company retracted the license agreement, and Linus Torvalds (initial creator and now benevolent dictator for life of the Linux kernel) took a week off and developed Git
A few common terms: A branch is a more-or-less copy of somebody else's code that you are working on, those are also called local branches.
You can have as many local branches as you like, and it is probably encouraged that you do so if you have multiple goals that you are working on at the same time.
Merges are where git largely autonomously takes two branches and merges them together.
A diff file is a difference file, which was created by Larry Walls (the creator of Perl) that shows the differences between two different version of a file.
Committing is creating a checkpoint of your code, and the common practice is to make sure your code at least compiles for you before committing it to version control.
That way if you ever revert, you can instantly recompile without any work.
git has various subcommands, like branch, merge, commit, diff, and init.
'git init' initializes the current directory (typically the root of a source code directory tree) to be a git repository. to undo this, simply delete the (invisible) .git folder in the directory. this is only necessary when you are starting a coding project, and is not useful nor necessary for branching from somebody else's repo.
'git add <file/s>' adds a file/s to the git file tracking system. This means that these files are "under" version control. Every commit to these files will be recorded by Git.
'git branch <stuff>' creates a branch from repository. the workflow after this command is to make changes and then commit the changes to the local branch with 'git commit' and eventually send a patch upstream with 'git diff' or push it to an upstream repository with 'git push'.
'git commit -m "Comment"' creates a checkpoint of code that should compile. The comment is used to tell people what you added/changed and most importantly, why you did what you did. Feature additions should probably be immediately obvious as to why they were added (so you just have to say what feature you added), but if the feature is not necessarily immediately useful or if the feature is contested with somebody else on the project, explaining why you added that feature is a good idea.
'git diff' creates a diff (difference file) between the current code (that is not committed) and the last commit, or the last commit and the first state (after a git init or a branch). You can specify an output diff file that git will create, and you can send that diff file (also known as a patch or a patch file) to a main developer for review and possible inclusion.
'git push' pushes your changes to some upstream repository. I'm not sure about the permission you need to do this, but some projects (like the X Server and the Linux kernel) have leaders who are the only people allowed to push to the main repository. The point is to get code reviewed before it gets committed to the main repository, so the patch can be tweaked so it doesn't break anything, or so it adds even more features or fixes more bugs. Also, sometimes the whitespace of a patch is not acceptable by upstream developers, so the submitter has to reformat the patch with the correct whitespace formatting. This matters more than you would think.