I generally do not get into version control wars. Working in large firms often means you are told what to use. It is less often the case that you get to choose. A whole ecosystem is then stood up around version control – people to support it, specialized hardware, processes, separation of duties and what have you. All for a good reason, but developer productivity falls over time.

Try doing this where you work (only if you are in a large regulated firm). Get the code from your repository…..now go home, throw the VPN away. What no connection to the mothership! Yes no connection. Now go through the script below.

• Assume you are on version 2.5 of your application. You would like to see the difference between certain files in 2.5 against an old revision 1.2.
• You then decide you want to add a new feature. So you decide to branch (branch-1). Some of us like branches. And why not – why mess around with the main code.
• Add some new code.
• Check that in.
• Damn I want to try out a different way of doing this, but don’t want to mess with this branch – again.
• Switch to mainline and create another branch (branch-2).
• On branch-2 I try out my new approach. Got it working. Check it in.
• After some thought I decide that branch-2 is the way to go.
• Delete branch-1.
• Then merge branch-2 back into mainline.
• Finally delete the temporary branch-2.

Can you do that where you work in a matter of minutes? I bet you cannot. Your CM team would be throwing fits, your requests for branching would send red signals up the corporate chain.

Well let me tell you that the script above is possible with Git – the open source distributed version control system (DVCS). This is not about which version control is better. Read about it, if you like Git great otherwise move on. Mercurial SCM is another open source DVCS and its usage is very similar to git. Instead  of using the command “git” you use “hg”. I cover Git here.

Git begins with the notion that all you developers are equally powerful – what a novel idea! When you bring down code from say a central location – you bring down everything, including history. You can cut the network cord now and you can perform the entire script above.

If your intention was instead to check in a project into GIT then run commands…

>> git init

>> git add

>> git commit -m “initial checkin”

If your intention instead was to check out an existing project from a central source – run commands…

>> git clone <url>

Either way you can now start working on this mainline project code. To start either tracking new files or update existing ones you use the command

>> git add [filename] [filename]

The “add” command simply stages the file to a local staging area. When you are ready to finally check in your changes, run command

>> git commit -m “your message”

The “commit” command creates a snapshot containing all the files you previously added. You can use the git “status” command to see what changed since the last check in.

Now realize that these commits are still being done to your local Git repository. Your code base is fully distributed (in its entirety) across all your users. Each user has the power to run our test script in complete isolation from others and no dependency on a central server.

Now if you had to branch, you would run command

>> git branch <branchname>

To switch to that branch run

>> git checkout branchname

Add a few files, run the add and then the commit command. Now switch to mainline by running command

>> git checkout master

“master” is the name representing the mainline.

If you check the directory now, you will not see the files you added to the branch. That work is kept isolated with the branch. Switch back to the branch and you should see the new files. Git takes care of synchronzing the contents of your folder with what your current branch is. No maintaining multiple directories. Elegant and useful.

Finally you decide to merge the work in the branch into the mainline and then delete the temporary branch.

If you are unsure which branch you are on run

>> git branch

This should list all branches and the master  – with an asterix preceding your active branch.

Switch to mainline if you are not already there

>> git checkout master

Run merge

>> git merge test

You should now see the new files have been merged into mainline. Finally delete the temporary branch

>> git branch -d test

Git gives you complete revision history all the way back to the first commit and also gives you the ability to perform inexpensive branching locally to work on different work items. Each commit keeps track of which files were modified/added during the commit as a changeset. This changeset can then be reverted using the unique id assigned to each commit.

Finally the question in your mind. How do I share code with other folks. You use the “fetch” and “pull” commands to synchronize with a remote server and bring down the latest changes. To upload changes you perform a “push” command.

Hopefully I have at least created a little interest in you for Git or distributed version control system (DVCS) in general.