By now, you’ve probably heard a lot about version control system software. As web developers, we often work on local development sites and then, upload everything once we’re finished.

But, what about when we have to work on larger projects with lots of complicated components (and with larger teams)?

We turn to version control software.

Today, we’re going to talk about Git and how we use it at Testomato. If you’re a seasoned Git user, feel free to skip this post, but if Git is unfamiliar to you. Read on.

We won’t be covering Subversion (SVN) here, so just a heads up, this is not a comparison between the two.

What is Git and why does Team Testomato like it so much?  

Git is an open source distributed version control (DVCS) that allows more than one person to work safely on the same project without interfering with each other.

First of all, version control software allows you to have “versions” of a project, meaning you can view changes to your code over time and backtrack to undo changes if necessary.

Since Git is a distributed version control system, it mirrors the entire version history. Basically, this means your workflow is secured because each developer has a complete copy of everything. If a server should fail, then your code can be restored from anyone who has the latest version.

It doesn’t have to have a centralized server, but can synchronize with other Git repositories. You can add multiple remote repositories (both read-only and write access), which allows you to create creative and flexible workflows.

We chose to use Git because it provides our team with a simple tool that delivers the flexibility and security we need to develop Testomato.

The two core concepts of Git – forking & branching

Since Git is an open source software, it has a strong foundation in the idea of forking. A fork is when someone takes the source code of another project and works on it separately from the main repository. Essentially, you can look at someone else’s code and then, take it whatever direction you want.

If you feel the changes you’ve made to the project are good ones, you can make a “pull request” to the author to pull your changes into the original code. Forks allow thousands of developers to work on any project at different points without the need for write access. In some cases, this can lead to competing versions of a project, but in general, Git encourages and enables easy collaboration.

Branching is something that’s done internally within a repository by its internal set of developers. You could look at a branch as another name for a section of development. Developers can work on a specific issue or feature without having to commit it or merge it with your master version. There’s no limit on the amount of branches you can have on a project, and they will never interfere with each other unless you merge them with other branches or back with your master. Essentially, it allows you address problems or work on new parts without the chance of breaking your main files.

Here’s a great example of a workflow by Vincent Driessen, which is very similar to our own model:


Which brings us to…how we use Git at Testomato!

If you haven’t guessed yet, we use Git daily at Testomato. As we mentioned before, Git integrates with all types of workflows, and we’d like to share ours with you.

Our developers use a combination of both feature branching and task branches in our Testomato repository:

  • Feature branches – For any work that requires more than one branch, we create a feature branch.
  • Task branches – For any single tasks, we add a new branch.

Each of our developers has their own space identified by their name, i.e. roman/[task nr]_whateverelse. If a branch is in your namespace, it belongs to them and no changes can be made by anyone else.

For example, work on our upcoming invoice feature would be filed as:

git checkout -b roman/t1068_invoices trunk

Our two most important branches on our repository: trunk and pre (we kept “trunk” from our early days using SVN).

  1. Trunk is our master development branch for code sharing between all our branches.
  2. Pre is the last stop before we release to our stable version on our servers.

Since our team loves everything to be fast and simple, we often use tags for automatic releases. This means we use the push command to push the tag release/[date].[number of release today], which will automatically send everything to our production servers.

If you’d like to take a look, here are the PHP scripts that we use.

A few other notes about our workflow that we think you might find interesting:

  • We prefer to rebase branches instead of merge them to maintain a clean history.
  • All developers are allowed to do hotfixes and merges on our Pre branch for upcoming releases.
  • If trunk is ready for a release, we’ll merge it to Pre and add a release tag.

There’s tons of powerful features in Git that help with a variety of issues, including debugging. In fact, we have an entire testing environment set up around both our main branches.

But we’ll save that for a later post.

Some recommended tools from our team

While most of our Git use comes straight from the command line, we do sometimes incorporate other tools:

By the way, what’s GitHub? 

Git is a tool to manage your source code history and while it can be run on a local server, you might want to use a hosting service for your Git repositories. That’s where GitHub comes in.

GitHub is graphical web interface for managing your Git projects, as well as a remote server and development community. It’s free for up to 5 public repositories and has low cost plans for those that want to keep their projects private.

You can also find Testomato on GitHub:

Are you a seasoned developer with Git experience? Are you just getting started and think you’d like to give it a try?

Let us know in the comments below or find us on Facebook. You can always tweet us directly @testomatocom.