This is and entry in a series about Starting Out In Development. The goal of this series is to provide brief introductions to critical tools, concepts, and skills you'll need as a developer.
Version Control Overview
Version Control. Maybe you've heard of it and maybe you haven't. But what is it, exactly? This post is an attempt to describe some of the basics of version control and the concepts behind some of the most popular implementations of version control.
Version control probably sounds more complicated than it really is. The core concept behind version control is actually quite simple. Version control is all about keeping track of the changes to a chosen file or set of files. In essence, you tell version control what files to track and it keeps track of all of the changes to those files. Not only does it keep track of changes, but it also keeps track of who did those changes, any comments they make about it, and when they made the changes.
Sounds simple enough, right? Good! Because it really is quite simple. There are some tricky situations you can get into especially as you get more advanced in your usage of version control, but most of the things you'll do in your career with version control are pretty simple and straight forward.
Before we get too much farther into this discussion, I think it'd be good to go over some terminology.
Terminology
Version Control System (VCS): The software application that keeps track of the changes to files.
Repository (Repo): Essentially a folder with all the files/folders that should be tracked by the VCS.
Add: Tell the VCS to track a given file/folder.
Commit: As a noun, this is a set of changes sent to the VCS. As a verb, this is the act of sending a set of changes to the VCS.
Revert: Undo the changes to a file and go back to a selected commit.
Basic Example
In this basic example, we'll be using one of the more basic implementations of version control called Subversion (SVN). We'll get into the details of why I chose SVN as the basic example here in a moment. For now, let's dive in to a simple use case.
Let's say that Bob, a developer, wants to start building a web site. He has this cool idea and he wants to make sure his progress is tracked and that if he makes any mistakes he can easily get back to a working state. So, Bob decides to use Subversion to keep track of the changes to his file. He sets up SVN and creates a folder (repository) for SVN to track.
So, Bob now has an empty folder. You can't build a website with no files, so he creates his first file, index.html, and adds some basic HTML to it. Now that he has the very basics of his first file, he wants to add it to the repository so that changes to it are tracked. So, he adds the file and commits the file. When committing, SVN asks for a commit message. In this case, he might say something like "initial commit." Now that he's added and committed the file, SVN is tracking the file and keeping a history of anything that happens to it.
Now that Bob has made his initial commit, it's time for him to get started on the real development. Bob adds a bit more HTML to the index.html file and creates a JavaScript file and a CSS file. After adding a bit of code and styles, Bob decides it's time to commit again. So, he adds the JS and CSS files and then commits all three files. Bob then looks at the SVN Log for his repository. Right now he sees two entries:
- initial commit - Shows that one HTML file was added
- Adding JS and CSS - Shows that the HTML file was changed and that two files were added
Bob then realizes that his idea for his website is much too complex to be using plain old JavaScript and that he'd rather use something pre-built so he doesn't have to reinvent the wheel. Bob decides that he doesn't need to keep any changes from commit 2, so he reverts to commit one and commits the changes. His log now looks like this:
- initial commit - Shows that one HTML file was added
- Adding JS and CSS - Shows that the HTML file was changed and that two files were added
- Reverting commit 2, removing JS and CSS - Shows that the HTML file was changed and that two files were removed
Review
So, we've walked through a very, very basic example. We talked about adding files to a repository, committing changes, and reverting changes. We'll get more into the details of how, exactly, to do these things and more in later posts. For now, this hopefully gave you a taste of how version control systems can work. Obviously this is a very trivial, basic example. In the real world with multiple people working on the same code base, things can get much more complicated.
Why Version Control?
While we've touched on this a little bit, I wanted to take a step back and talk about why use version control. Here are some of the advantages of using version control:
- Have a traceable history of all changes in the entire code base
- Have a "time machine" of sorts where you can easily revert back to a given commit
- Easy way to undo changes
- Easy way to see who made what changes
- When used properly, can be a great way to facilitate code reviews
- Helps coordinate work across multiple people, teams, and geographies
And the list goes on. Throughout your career, you'll experience many of these benefits and more.
Conclusion
So, there you have it. There's way more to cover on the topic of version control, but I hope this was a decent introduction into version control. You can look forward to a post from me on SVN and another covering Git and how to use each one and the differences between them.
Version control is a great tool that you'll frequently use throughout your career. Many schools historically don't spend a lot of time in VCS. Thankfully that is changing, but it can be challenging starting in your first job if you know very little about VCS and then suddenly everything you do needs to be in VCS. Spending a bit of time early on in your education or career learning about VCS and using them can give you a leg up on the competition when trying to land that first job.
Comments
Post a Comment