Version Control Vocabulary

Mitchell Wright
Mitchell Wright
Sep 24 2018

After watching this video, you should be able to understand and explain a number of core version control concepts. Ten terms, 10 minutes. Let's go. 

Version control is a system that lets you manage changes to files and projects. With version control, you can incrementally build your work knowing you've saved a safe copy at each stage of development. And if, or perhaps I should say when, you mess up, whether you mess up just a tiny bit or a lot, you can just rewind the clock and get back to where you were before you made your big oops. Version control has several names. It's also called source control or source control management. Version control and source control are the same thing. Theoretically, it's also called revision control, but you can more or less ignore that. Pretty much nobody uses the term, but you're going to hear source control and version control a lot.

The most common version control system for most development projects is Git. And the most common place you use Git is either directly on your computer or at github.com, which is a commercial hosting site for Git projects. Like all version control, Git lets you save incremental versions of your work so you can review changes over time.

Each Git project is called a repository. A repository stores all the files in your project as well as the changes you made to it. You can think of a Git repository more or less interchangeably as a project, except it's a project that has memory. You can move back and forward in time, and you can look at the ways you have changed and modified your project and that's what a repository does. It stores data and it stores change information. Repository is pretty big word, so most people just call it a repo. 

Here are the three big things you do with version control. You commit, you clone, and you branch. When you commit a change, you add your latest changes to your repo. You're saying take this info and file it. As in life, commitment is a serious responsibility. And that's why every commit needs a serious commit message. A commit message explains what you changed and it's the primary way that you communicate about the change to the rest of your development team. When you commit, you push your changes to the repository, all the information heading upstream to your repo is pushed. When you push you're shoving information from your local source into the shared repository. Every time you commit there are differences between the project from the last save point to the new one. And these changes are called diffs. You can compare changes between commits by looking at the diffs. And diffs is just short for differences. 

So, what happens when you attempt to commit a change to a file and somebody else has already changed that file? You have conflict. A conflict happens when two parties change the same file and there's no automatic way to reconcile the changes. You must resolve the change by selecting which change wins. When you clone a repository, you create a local copy to work on. Your version matches the contents of the repository at the time you cloned it. And if there's a cool repo on GitHub you'd like to look at, you can clone it to your computer where you can compile it from source, modify it and more. Cloning lets you start working locally. If you've been working on a clone project, you may need to catch up with the changes other people have made. If so, you'll need to pull. Pulling changes copies revisions from the repository to your local copy. 

There's another way to copy repository which is called forking. And forking has nothing to do with these things. Forking is more like a fork in a tree, and I'm gonna warn you now that when you work with version control, and especially with Git, you run into a lot of tree metaphors. When you clone you make a copy on your computer. When you fork, you make a new repository, typically on GitHub, or whatever hosting site you're using. A fork has all the contents of the original, but you are now the owner of this new repository and you're starting a new development project. You're copying a project when you fork and you're working on a project when you clone. 

This is a sample repository on GitHub. I can clone the repo to my computer and work on it there. Or I can fork the repository to create a new repository that I own. If you notice, the original repo was built by Lambda schools, but my fork is owned by me. Forking and cloning are essential to contributing to open source and closed source projects. If I make an important change to my version, to my forked version, I can then submit a pull request and request that the original team adds my updates to their project. If the project owner or the project maintainer agrees they will merge my pull request as a new commit.

Branches let you create alternate versions of your project. They're like trees again. When you branch you can work on new features and try out new ideas without messing up your main work. Your main work has many names. You can call it a trunk like a tree trunk. It's commonly called the master or the master branch. You may also hear the term baseline. The trunk or master is where your team keeps its primary project development and if you mess it up, people will get very, very cranky. So, if you're going to work on something that will take a while and may break your build, make sure to branch so you don't mess up everybody else's work. One more term, remember how you cloned a repository? Well you check out a branch. Checking out lets you move from branch, to branch, to branch, and it makes sure that you're only working on the parts of the projects that you intend to. 

Okay, so that's the vocabulary for version control. Here's a quick review. Repositories store information. You clone repositories, you commit changes to them, and then you use branches to keep each bit of work separate. You push changes to a repository, and you pull updates from a repository, and you always use good commit messages. Each commit adds a set of changes or diffs. You make sure to resolve your conflicts if they arise. And finally, you fork projects if you want to work on changes for your own use, or to submit to the original project through a pull request. So, there you have it 10 minutes, 10 terms. You'll be using these words a lot as you work on Version Control. Have fun and make sure you remember to commit.