Better Continuous Integration with Git

 Git is becoming very popular now, at least for open source projects. I wanted to blog about how Git could be useful for the enterprise.

There are enough blogs about how you can use Git for private branches, or sharing code between team members without muddling the main repository, so I won’t go into that.


Git can also help you achieve better continuous integration. How often have you committed code, after compiling, only to discover the nightly build fails? Usually this is caused by some file you forgot to add to the VCS, or some other dependency that exists on your computer, but not everyone else’s.


One of the powerful features of Git is that everyone works on his/her own copy (clone) of a repository. Git is actually a tool for synchronizing repositories, not for synchronizing a working directory and a repository which is what SVN, CVS and the like are. This means every developer can have a repository on a central computer that is monitored by the continuous integration server. When a developer finishes work on a feature, he first pushes his changes to his private repository. The continuous integration server starts a build and the developer is notified if it succeeded or failed. If failed, the developer can fix the issues that caused the failure (without being stressed that others cannot work, as happens in SVN) and repeat the process. When the build is successful, the developer pushes his changes to the central repository.


Here is a diagram of the setup:



The easiest approach to hosting several such repositories is to use tools similar to github. Free ones are gitorious or bananajour. These allow creating a ‘mainline’ repository for people to pull push to and cloning it to private repositories. Using these, Hudson jobs can be created to monitor the repositories and build when necessary.


Thank you for your interest!

We will contact you as soon as possible.

Send us a message

Oops, something went wrong
Please try again or contact us by email at