Up until a few months ago, I had no real reason to incorporate an accredited version control regimen in my Drupal development projects. I was primarily working alone and abided by a strict schedule for my own backups and version control tracking. I am adamant on this detail and completely understand the importance of such a procedure, but it was only me working on my own.

A couple of months ago, I was invited to join a team of designers and developers in a group project. It was the first time that I had to get my head around a distributed version control methodology. Knowing it is really the only way to effectively collaborate with other developers, but how does it work?

Distributed Version Control Systems (DVCS)

It would seem that the method of choice in today’s development world is the distributed, opposed to the centralized, version control system. DVCS works on a ‘snapshot’ of the database as opposed to maintaining a complex record of the changes made–a record of differences, if you will. Every checkout of a DVCS can be considered a full backup of the project.

The obvious bonus here is the whole redundancy aspect across the team, a duplication that could save the day if the very worst thing happens to your server.

Another distinct advantage of a distributed system is its ability to establish a hierarchical structure of repositories. Such a set up can facilitate different smaller groups to work on different aspects of the same project at the same time. This is where my head starts to explode, thinking that things could get quite confusing very fast.

Virtually every operations is local when working with a DVCS, resulting in an increase of speed and the ability to work without being tied to the server. The whole history of the project is right there on your computer.

GIT: Version Control System

Let’s get to know GIT.

There are a number of these systems available on the market, but by far the largest and most used system is GIT. It has an amazing website with excellent documentation and tutorials. Don’t forget: Youtube is your friend.

Getting Started Git Basics is the basic guide you’ll use if you’re new to the GIT system. I read it about three times and then the light started to twinkle; actually, I keep going back to it. I find returning back to the basics helps me to move on.

The GIT process

There are three sections in the process that you have to thoroughly understand:

GIT Operations.png

The Git directory is where all the associated files for your project are stored. When you want to work on a particular version of a project, you would clone a repository of this directory.

The working directory is that single checkout: one version of the project. These files are pulled from the Git directory and placed on a local computer for the developer to use or modify.

The staging directory is a single file that stores all the information it has gathered during your modifications. It’s the data that will accompany your next commit.

A Work In Progress

Let me continue using GIT for my Drupal projects and I will report back shortly will the next steps. I have a computer here at home on which I have to install Git; I will do that over the course of the week and report back.

How do you use GIT for your development projects? Any tips to help me get started and use this tool effectively?