I'd heard of version control before I got to Dev Bootcamp. (Technically, I'm not at Dev Bootcamp now — I'm in the first week of the 9-week remote preparation course DBC calls "Phase 0".) I'd made a GitHub and BitBucket accounts for online courses I took while teaching myself basic programming. I even did two short courses through Udemy that focused specifically on git and GitHub. But it still seemed like sorcery to me. I'd recite the incantations as best I could, and sometimes the right thing would happen, but I was never quite sure what had happened and why. Eventually, I'd get confused and frustrated, and go back to haphazardly archiving versions of my project in Dropbox folders, putting off real version control for later.

Well, now it's later. I'm enrolled in Dev Bootcamp, and the first week of Phase 0 is all about version control, so I can't avoid it any longer. Sure, some of the Week 1 assignments say they're about other things, but they're really mostly about practicing creating, forking, cloning, branching, pushing, pulling, and merging repositories on GitHub. I'm still not certain about everything that's going on, but at least I've learned the basics. Here's the little that I know...

You can't afford to be version averse

As a coder, you can sort of limp along without version control — as long as you're working alone. As soon as you want to collaborate with even one other developer, the risk of things going suddenly, sickeningly wrong goes up by several orders of magnitude. One person may save over another person's work, or delete key files, or have a brilliant idea for a feature you cut three versions back. Development teams need a system that lets them share project files, edit them, add to them, merge them back together, and archive them so that old versions can be recovered and restored if necessary. A real version control system — like git and GitHub — does all that for you.

Here's what version control does, in a nutshell. A master repository for all the files that make up the project is created on a system that is accessable to all members of the development team. Each team member can download (pull) a copy (branch) to her own computer and work on any and all files...while everyone else is also working with the same files! At appropriate intervals, each team can upload (push) their branch back up to the master repository, compare (compare, believe it not) their files to those in the master branch, resolve any conflicts between the two versions that are discovered during the comparison, and them merge their changes into the master branch. A complete archive of the entire project is saved with every such update, along with a message detailing the changes made; if necessary, all or part of any archived version can be recovered and re-incorporated into the ongoing project.

With version control, you no longer have to worry about losing work when someone accidentally saves over or deletes a teammate's files. If a fatal error gets coded into the project, you can roll back to the last version without the problem, instead of starting over from scratch. And if you want to explore different options for the project — such as whether or not to redesign the interface or include controversial features — the team can create a separate branch (called a fork) and continue to develop both versions in parallel, eventually deciding whether to merge them back together, or to abandon one fork entirely. Version control offers development teams both security and options that aren't available any other way.

git'er done with GitHub

Once you've decided to use version control, you have to pick a system to use. Unless you're required by a client or employer to use another, the best choice today is git and GitHub, which is the most popular version control system and service in the open-source web-development community. It's the pairing that everyone knows, and everyone expects you to be comfortable with. The git software is free to download and install, and GitHub serves the open-source community by offering their services and servers for free for all public repositories. But what's the difference between git and GitHub, and why would anyone need both?

git is a version-control system originally invented by Linus Torvalds to support the open-source development of the Linux operating system. It is a program that is installed on your own computer, where it saves and manages file repositories locally. git is best operated using the command line, instead through a graphic user interface — which is part of why it's daunting to learn for many modern computer users.

GitHub is an internet-based service which allows users to store and share their git repositories online, enabling teams of developers to communicate and collaborate on version-controlled projects regardless of their physical location. Users manage their online repositories using GitHub's graphical interface, but local git operations must still be performed from the command line. GitHub relies upon git, but git is not limited to GitHub; git can be used locally without GitHub, or in conjunction with a rival service such as BitBucket. GitHub is free to use for public repositories, but charges a fee for hosting private repos.

Now git going!

To install git, you'll need to follow the directions at the git website — the procedure will vary according to your operating system. It's easy to make a GitHub account, though, and tutorials on the GitHub site will help you get started using it.

Once you've installed git and made your GitHub account, you may (or may not) find these walk-throughs of common git tasks helpful:

• Create a GitHub Repo — How to create a new repository on GitHub and clone it to your local system
• git Workflow Walk-through — How to begin and end each day of software development in a git-controlled project.