You’re working on a new project, and the client asks for a new feature that wasn’t in the original proposal, you add the feature, and a few months down the road the requirements have changed again, and the client decides that the feature just won’t do.
You look at the source code, and realize that you had to change almost every file in the project to make it work, and now you are looking at hours of re-coding to fix the problem … Enter version control. By using a fork you can make the change that client asked for, and easily remove it with a quick command or the click of a mouse.
You get a phone call from your manager, apparently your code base has been compromised by a hacker. You don’t know what files were changed or how, so you are now looking at hundreds of hours of pouring over every line of source code to make sure nothing has been tampered with.
Enter version control, with a version control system in place, you simply would restore a previous version that you know has not been tampered with and presto all changes that the attacker made are gone.
There are hundreds of such use case scenarios, and even simpler ones like the ability to try new code without affecting your base that make version control systems such a vital part of the development cycle. So what is a version control system?
Version control is a system used by many software developers to track changes, and work collaboratively on projects. Some of the most popular version control system include GIT and SVN. In this blog I’ll discuss the advantages and disadvantages to using a version control system, some popular websites, and of the most popular version control systems git.
Git is a popular version control system originally developed by Linux creator Linus Torvalds. When relations between the linux foundation and BitKeeper broke down, and it’s free of charge status was revoked, the linux foundation and most Linus himself decided to develop a tool that he could use to work on the linux kernel.
Git started it’s life as a command based tool that worked in Linux. It’s primary objectives were to be lightweight, easy to use, and distributable, allowing teams to work together on projects at the same time without tripping over each other. Since it’s creation, it has been ported to work on Windows as well and even has a friendly and robust GUI.
When using Git you work on a series of branches and use commits to “save” your work at a certain point on the branch. These commits allow you to go back and review the state of your project as it was at the time of the commit. Branches allow you to create a sandbox to work on a project without cluttering the main line. The advantage to this is allowing you to try something and if it doesn’t work or you later decide to not include it, you can delete the branch without losing all the work you had done on the master or other branches.
So what exactly are branches and how are they used? Every project has what’s known as a master branch. This branch is created when you initialize your project in git and is where the projects code base resides. While you are developing your project you may find instances where you want to experiment with a piece of code or implement something that modifies many files. Without a content management system, you may find yourself copying your source code and creating a backup that you can revert back to incase things go wrong; Git’s branch system acts a lot like this, only instead of multiple copies of the same file, git uses branches.
When you want to start a new branch you simply issue the required command and give your new branch a name. Your branch starts out completely empty similar to when you start a fresh project and you add, remove and modify files as you would normally. Once you are finished you commit your changes. Git stores all these changes separately and allows you to easily go back the master branch, and even start yet another branch. Once you are finished with a branch you can then merge it back into the master applying all your new changes, or you can discard it.
The great thing about merging a branch in git is even when you make changes to the main branch, git is smart enough to apply your changes to the most recent files with little to no intervention on your part, eliminating many of the version control issues.
Committing is a term commonly used in git and version control systems in general. When you commit something in Git you are making a checkpoint for all the files you are currently tracking in the current branch. When you commit your work you are asked to provide a commit message which should be descriptive and in the past tense describing an action for example I were to make a commit for this article I might choose “Added section about git” in my commit message. A meaningful commit message is vital especially if you want to be able to go back to a previous point in time, or when you are working in a team environment where several people may need to understand the changes you have made.
When you make a commit on a branch, that branch is the only one affected by the commit. So if you commit on the master branch, all branches that were created before that commit do not inherit the code from the master, and are treated independently. Same goes for a side branch, the master does not inherit the code of other branches and is treated independently of them. Once you decide to commit a branch, git tries it’s best to determine what changed and where and merges the files together at that point.
No post talking about version control and git would be complete without mentioning one of the most popular git repository websites GitHub. Github is a social coding site and centralized repository. It allows you to make your projects available online either privately or publicly and gives the opportunity to easily allow you to work with a team giving permission for the members to contribute directly to the project, and also allows the general public to send pull requests, which basically means including a branch they developed based on your project.
What makes Github such a great tool is that is provides such excellent collaborative tools. If you like a project you can fork it, giving you complete access to the source code and allowing you to edit it. If you create something awesome you can send a pull request to the original project and they can choose to accept it, in which case you would become a contributor, or deny it in which case you can either continue on your separate branch and create a competing project, or move onto something else.
Is Version Control the Right Tool?
The debate about when to start using version control on a project, and even when to do your first and consecutive commits is a topic that is hotly debated. However there are some things to consider when deciding if you should use a VCS. The first thing to consider is the size and scope of the project. If your project is going to take a good amount of time or requires a lot of development then having a solid version control system may be beneficial, conversely if you are making a quick program to perform a simple task (or even a macro) then it may be overkill.
The other thing to consider is collaboration. Tools like Git exist to make social coding a simpler process by tracking changes and making file merging possible. If you want your project to be easy to manage across multiple people or even run an open source project with public contributors then having a VCS is almost a requirement. However audience is also an important thing to consider, and if the people you are working with are not familiar with version control then the learning curve may make using one a difficult or impossible prospect.
Finally if you are unsure if your project will become big enough or active enough to use version control then you should start from the beginning. The excellent thing about systems like GIT are they are very scaleable. You can manage your repository locally for projects that are independent or small, and then easily scale them as they grow or you add more members. This allows the whole team to follow what you have been working on and why you may have made certain decisions, or when a certain bug was introduced.
Although GIT is powerful robust, and a useful tool the learning curve for using such a tool can be quite steep. The best way to start using git is to get your hands dirty and try it with some smaller projects. You can start one on your own or even fork one on the popular github. Feel free to grab one of mine <https://github.com/pyrodesign>.
There are also many popular online and print resources available, I’ve listed a few below for convenience.
Pro Git – Scott Chacon
This is a great resource available on amazon as well as straight from the git website, and contains everything you could possibly need to know about how to use Git. This book is also very helpfully free for online viewing and licensed on licensed under the Creative Commons Attribution Non Commercial Share Alike 3.0 license
This website contains various resources including access to web based and in person training, and even has a quick interactive tutorial on using git and a web based repository.
A good website including tutorials and links to further resources on how to use and learn git.
There are also millions of resources, blogs, and forums available on the world wide web for you to choose from. Just choose your favorite search engine and type “e;learn git”e;