Version Control with Git


I am in the process of setting up my environment for my first personal software project. There are two tools that I am in the process of trying to understand, version control, and automated builds. In the past I have dabbled in Subversion, however the more I browsed around opensource projects the more Git had shown itself to be prevalent and prominent in the opensource community. For that reason it was decided that Git could no longer be ignored.

Having read many forums and “discussions” as to the differences between Git and Subversion, I decided that I wanted to give Git a whirl. It’s not that Git is better than Subversion, just that Git is different and has some advantages that resonated with me – the developer. I suppose that is what is most important. It the version control system appropriate for you the developer and the project you’re working on.

The benefits that Git provided that was of particular interest to me was that it was a decentralized system. That meant that I could have a copy on my main desktop pc, and another copy on my laptop and synchronize changes by pushing and pulling from each other. The major benefit over Subversion is that you can work on the repository “offline” without having to commit your changes to a single server. User and other developers can than pull changes from each other or push their own changes to a central repository at will. Git is a complex VCS that is in my opinion a technological achievement and very very flexible.

Having tinkered with it for a few days I have now set up three repositories, one on a easily accessible host on my home network, one on my desktop pc, and one on my laptop. I can now synchronize between all three repositories with relative ease.

There is one thing I have yet to figure out. I can update the repository with changes, and I can search the logs for all the commits that I have made. I can even compare changes between commits. The question I have is, what do you do when you want to roll back the repository, or at least roll back some changes that were made that didn’t pan out? How do you roll back the entire repository when the last integration breaks the build? These questions are yet to be answered, but I am confident that I will know the answers soon.

But what this experience has taught me, is that Git is in fact a very good version control system to use. Here is an overview of what the system is design for:

  • Frictionless Context Switching. Create a branch to try out an idea, commit a few times, switch back to where you branched from, apply a patch, switch back to where you are experimenting, and merge it in.
  • Role-Based Codelines. Have a branch that always contains only what goes to production, another that you merge work into for testing, and several smaller ones for day to day work.
  • Feature Based Workflow. Create new branches for each new feature you’re working on so you can seamlessly switch back and forth between them, then delete each branch when that feature gets merged into your main line.
  • Disposable Experimentation. Create a branch to experiment in, realize it’s not going to work, and just delete it – abandoning the work—with nobody else ever seeing it (even if you’ve pushed other branches in the meantime).

If you want to find out more about Git and its capabilities visit the official homepage –

Comments are closed.

Powered by WordPress. Designed by Woo Themes