Source Control… Git It?

So you have this new web-development project… Its massive, pretty huge and well, you can’t handle this one on your own (Ten points for recognizing that….). So yeah, you decide to get a couple of your buddies so you can put your heads together and take down the behemoth quickly and easily… But wait, Your CSS guy lives ten miles away, One of your backend guys is a night owl and the other well, he has a day-job, is a little crazy and perhaps suffers from a bad bout of agoraphobia and lives in some cave under someone’s stairs, But hey, These are your guys, your team and the project needs to be done. Then the ugly question raises its head from the muck… How do you collaborate?

A few years back, approached with the same question, I would have come up with some ingenious plot of how to use emails, and some file sharing service like Dropbox or some other means of constant copying and passing about flashdisks and stuff. All very slow, very dangerous and with a high probability of code corruption. Questions like “What happens if Jack edits my code?”, “What happens if a file is deleted?”, “What happens if new methods need to be added to someone else’s code?”… rise up and one is left looking for a solution… And the solution is…. [Drumrolls….]: Version Control

Revision control, also known as version control and source control (and an aspect of software configuration management), is the management of changes to documents, computer programs, large web sites, and other collections of information.

Wikipedia…

Think of revision control or as i prefer to call it: Source Control, as a simple way that various people can work on the same code base with ease.

Terms:

I’ll not get into the nitty-gritties of source control and how it works on the backend…(That’s for another day…), Various Source Control Systems come with various terms that are unique to them but a few terms are universal:

• Repository This is the Code Base, It can be local (on your computer) or Remote (on an online server).
• Get – retrieve a specific set of changes (files, directories, etc) from the repository
• Commit – add a specific set of changes to the repository

” So how does it all work?” you ask, Well, its pretty easy, In general, what most Source Control Systems do is create an index of the code you currently have. When changes are made, they are committed i.e. added to the local repository. You can then push them online to the remote repository. This is the most basic form of Source Control…

“But what happens when I have many developers?” Ahhh… Here is where the true beauty of Source Control reveals itself. All you have to do is set up an online repository an have your various developers pull from it (Get the files from the online server). When any of them makes changes to their local repository and pushes the changes online, any other person who pulls, will pull the other developer’s changes hence updating their version of source code.

“What if I don’t want to mix the code?” Beautiful question… That’s where forking and branches come in. A branch is basically a version of the original independent of the original..(WTF??… just think of a tree). It is a fork from the original that gets merged back. Each person can create a branch from the original repository and make changes to the branches. Branches are independent of each other( Just like in a tree…) and changes to a branch therefore remain in that branch. But what happens when its all over? Merging… Two Branches are brought together and fused (Not like in a tree…) . “Conflicts?” you ask… Files that have been edited by two different people are brought up so that the code from both (or more) parties is compared and the right sections chosen.

“What the fork?” Okay, it seems a little complex to start with but its as easy as pie (definitely not as easy as pi… Math Joke Fail… #facepalm). Its amazing… Think of it this way, if you lose your code, you can recover it, If you make an error and get lost, you can backtrack to your latest commit… If you’re a group, you can enjoy both independence and cooperation.

Version Control Systems:

There are lots of version control systems out there but i’ll just give the main ones an honourable mention:

1. Subversion:

Subversion is probably the version control system with quite a fanbase. A lot of open-source projects use Subversion as a repository because other larger projects, such as SourceForge, Apache, Python, Ruby and many others, use it as well. Google Code uses Subversion exclusively to distribute code.

Thanks to is popularity, there are many clients available. If you’re a Windows user, Tortoise SVN is amazing. If you’re on a Mac, Versions is an elegant client that provides a “pleasant way to work with Subversion.” Xcode is Apple’s developer environment and ships with Subversion.

2. Mercurial:

Mercurial is an open-source distributed version control system whose popularity has risen in recent years.The name “mercurial” is an adjective that means “Relating to or having characteristics (eloquence, swiftness, cleverness) attributed to the god Mercury.”

Aside from being very fast and scalable, Mercurial is an apparently simpler system than Git (I tend to find them quite similar… ), which is why it appeals to some developers. There aren’t as many functions to learn, and the functions are similar to those in other CVS systems. It also comes equipped with a stand-alone Web interface and extensive documentation on understanding Mercurial if you have been using another system.

3. Git:

Git is most definitely my favourite and the one I use to date (No favouritism Here…).Its a Version Control system created by Linux creator Linus Torvalds. It provides a distributed version control system. With a distributed version control system, there isn’t one centralized code base to pull the code from. Different branches hold different parts of the code. Other version control systems, such as SVN(subversion), use centralized version control, meaning that only one master copy is used.

It’s popularity especially in the open-source community is quite high and it comes with many tools and an easy learning curve.

Some Helpful Links:

7 Revision Control Systems Reviewed Source Control Done Right

In conclusion:

I still believe the best way to learn something is to go out there and do it. Grab a tool, check it out and have some fun. Source Control really does make life easier. The next article in this series will look at how to use Git for Source Control.

Got some questions… Don’t be shy and ask them below!!

Originally published at www.codegladiators.com.