In a perfect world, any coding project would have killer design, concise functional specifications, well defined technical specifications, and a client that understands how everything ties together prior to starting development. In the real world, designs are changed after being approved, functional requirements become nebulous based on ever changing information, technical specifications need adjustment after real-world testing, and clients change direction mid-project.
There are many ways to help mitigate these issues... better scoping, sign-off during multiple phases, iterative programming, etc. It is, however, very difficult to ensure that none of these items occur during complex projects. That being the case, you must have a plan in place that allows your development and quality assurance teams to control any code updates efficiently and effectively. This is where version control systems come into play.
Version Control Systems
There are many version control systems (Subversion, Concurrent Versions System, Git, Mercurial, Team Foundation Version Control) readily available to most development teams. This post is going to focus on Git. That's "Git" with a capitol "G" as to not be confused with "git" (an unpleasant or contemptible person) which is something you definitely don't want associated with your development team.
Git is a version control system that works off of the concept of a snapshot of code rather than simply keeping track of the updates. This means that each commit within the system creates a new snapshot of the system as a whole. Because Git utilizes a snapshot, it enables users to download entire versions so that they can be worked on in a local environment. Because a user is working locally, there is no need to be connected to the repository until a new commit is made. Once updated code is committed, the Git database is updated and a new snapshot is made. Each time a snapshot is made, it allows the developer to access the code as it existed at that point in time.
There are three basic states in which a file can exist in when using Git.
- You are actively working on a file that has been pulled from the Git directory
- You have finalized updates on a file and placed it in a staging area for a future commit to the Git directory
- You have committed the stage files to the Git directory which creates an updated snapshot
These stages allow individuals and teams to work on a group of files without fear of losing previous iterations.
Git is simply a tool that acts as the version control system and is the only piece that is required to start protecting your code. There are numerous services, however, that allow remote hosting of repositories. These services allow greater collaboration between larger teams and often introduce interfaces that make the process of pulling and committing much easier. GitHub is the most popular and is often confused with Git. Utilizing GitHub gives your team the ability to share repositories, a graphical interface, mobile integration, task management, forking and defect tracking.
Git and GitHub may not be the magic bullet that your team needs. As a development team grows beyond a handful of developers, having any type of source control is better than none and Git is better than most. As stated at the opening, Subversion, Concurrent Versions System, Mercurial, and Team Foundation Version Control are also viable contenders. It's not a matter of if you will, one day, need to get a previous iteration of code... it is a matter of when. Set yourself up now so that when there is an issue with recovering code you don't stop, you Git it Git it.