Do you ever wish you had a time machine? Maybe you would like to see ancient history first hand or re-live an important decision in your life? While we can’t travel through time and space, we can achieve a close second in our technical work using source control. Source control is kind of like a time machine for your plain text files.
A simple form of source control could work like the following:
- Do some work in an electronic document
- Save the file off with with a unique name at a given point
- Repeat steps 1 and 2 until the work is complete
This model works well for a small project with a single author. But this approach becomes problematic when different circumstances emerge such as
- Multiple authors are contributing work
- Two or more parallel works need to be merged into one work
- There are lots of files that need to be tracked
- Additional meta data is needed such as author, time and change notes
When one or more of these conditions emerge it becomes appropriate to utilize source control software. As is true with many universal problems in the software industry, the problem of tracking revisions has been solved with many different tools over time. As a frame of reference I have directly or indirectly dealt with seven different source control systems over the course of 14 years. A thorough comparison of source control systems can be found here: http://en.wikipedia.org/wiki/Comparison_of_revision_control_software As with other articles in this series we will focus more on the factors to determine the right tool and less on any one solution.
Factors to Consider When Picking a Source Control Tool
What file types are being stored?
Most often source control systems focus on the task of versioning plain text (i.e. code and code like artifacts). They frequently do this using a difference concept where the changes from one version the next are captured. This also means that while some solutions are great at tracking plain text changes, they can also be terrible at tracking “binary” files such as images and office documents. If you are working with binary files, source control systems might not be a good choice
What is your environment?
One of the reasons why there are so many source control solutions is because there are so many ways to make software. Your environment might include one or more operating systems, official and unofficial IDEs of the team, and graphical vs. terminal workflows. For example, if you are using a Visual Studio based work flow in a Windows environment, Team Foundation Server may be a natural fit because it is seamlessly integrated with specific versions of Visual Studio. On the other hand if you have have a mix of Windows, Mac and Linux hackers you might want to consider a Git solution paired with visual clients like gitk.
What are your resources?
Some of the popular source control solutions have a price tag associated with them. Even “free” software can have a cost when paired with cloud services with a prime example being private repositories on GitHub. Different solutions may also require varying levels of infrastructure. Do you have a person who knows how to setup a server securely or setup a database? This infrastructure also needs maintenance over time to ensure availability, performance, and security.
What does the team prefer?
Developer productivity is an essential element in delivering a quality product. Productivity and morale will suffer a developer has to learn a complicated system or constantly fight a tool chain. Developers and other content creators should have a major say in the tools they are required to use. It is true that most developers like learning new things, but introducing too many new tools or technologies cripples a teams ability to craft new solutions. Keep the number of completely new tools and technology to one or two if you want to have any hope of making your schedule projections.
Common Workflows to Master
Regardless of which tool is selected as the right answer, team members will need to master a few common work scenarios. These skills are essential and should not be schlepped off to peers. Address avoidance of these tasks immediately because they could be:
- An indicator that more hands on training is required
- An indicator that the wrong source control solution was selected
- An indicator that corrective action and coaching is needed at an individual level
Universal Source Control Tasks
- Add a file or files to source control
- Remove a file or files from source control
- Obtain the newest version of a file or files
- Obtain a specific version of a file or files
- View revision history for a file or files
- Fork or branch from a given version
- Join or merge two versions
- Roll back to a specific version
- Create a new version and share it with others
- View the changes between two versions
- Mark or otherwise annotate specific versions