Distributed Version Control

Speed and flexibility for agile teams

Distributed version control systems (DVCS) have gained popularity especially in open source projects. The most popular DVCS at the moment is Git, originally developed for Linux kernel development by Linus Torvalds.

The adoption of Git is best presented by the ever growing popularity of the social software development service GitHub. In July 2010 GitHub had amassed one million repositories. Ten months later in April 2011 the figure had already doubled to two million repositories with over 1.1 million Git projects.

The exponential growth of popularity has raised interest in DVCS also in corporations. Reaktor has found the new technology to provide concrete benefits and we have adopted Git as the version control tool for a large portion of our projects.

Distributed version control systems

The distinctive feature of a DVCS is that every checked out working copy of the repository contains the full version history. Changes are initially made in the developer's private, local repository – this is one of the fundamentals of distributed version control. The local repository can then be synchronized with other developers' repositories or, for example, published to a shared repository.

DVCS's offer a large suite of tools for managing, merging and publishing repositories. Many of the benefits of DVCS's are based on the greater freedom of viewing and manipulating version history. These operations tend to be quick, too, because they do not need to communicate with remote servers.

Change sets are considered as changes to the state of the whole repository rather than as changes to individual files. Git, for example, handles version history such that it can identify identical changes made by two different developers. These features make merging of change sets less painful than usual.

Flexible workflows

Each developer having a full copy of the revision history opens up new possibilities for development teams to organize their work. It is possible to employ the well-known shared repository model in which all developers publish their change sets directly to the shared repository. However, the distributed architecture enables other ways of sharing and distributing change sets.

In the fork/pull model used in GitHub every developer publishes their changes to their own public repository. Instead of authorized developers pushing their changes to a shared repository, developers pull change sets from each others' public repositories into their own private repository. In this model one of the repositories is usually picked as the official repository that releases are cut from.

One example of the fork/pull model is the JUnit project administrated by Kent Beck. At the time of writing, there are 109 forks of JUnit, some of which may have moved to drastically different directions than Kent Beck's repository. The official JUnit releases are made from Kent Beck's repository, however, to which he has pulled the changes he has considered adequate for the product.

Another model for development is the patch model familiar from Linux development. In the patch model developers email patches to module maintainers. Maintainers review the patches and accept the ones they consider relevant, merging them to the official version history. A benefit of the patch model is that the patch sets can be reviewed and discussed in depth before they are merged. The resulting version history is a linear stream of changes that have been reviewed and discussed by multiple observers before making it to the product.

Freedom to manipulate version history

Modern tools for distributed version control arm the developer with greater freedom of examining and modifying revision history. They make it easier to pinpoint bugs in version history and to publish of service releases of the software. The tools make jumping between and modifying branches a breeze, which means that fixing a bug in some old branch and merging the same bug-fix to the most recent development version is that much faster.

Another advantage is the ability to modify change sets before publishing. For example, a developer can squash commits, split up large commits and rewrite the commit messages when he has finished developing a complete feature and gained a more thorough understanding of the changes needed. These tools support good practices and make the everyday work easier.

Git for agile teams

Git gives the developer a lot of power and enables operations that aren't feasible with traditional version control systems. The biggest benefit Git has to offer for agile teams, however, is much simpler than that. Speed. The speed with which Git carries out common tasks lowers the bar and encourages developers in making use of those procedures. That, in turn, means that teams are using their version control system in more versatile and effective ways.

Heikki Rauhala, senior software developer

Heikki is an experienced software developer who picks the right tool for the task at hand.

Lasse Koskela, agile coach

Lasse helps individuals, teams and organizations find more effective methods and practices for product management and software development.