Our Git workflow: Introduction

Git is a version control system that is commonly used throughout the Open Source community. Since there are a lot of users, there's also a lot of different ways to work with Git in order to maintain a proper history of your work, maintaining different releases of software, and to cooperate with other developers without any conflicts.

We were 4 people when we started using Git, and all we did was to create simple presentation websites. This made it quite easy to simply get going with Git since we didn't have to think about external developers, different environments, etc. And because everybody knew what the others were doing, it was almost impossible to create conflicts. As of today, we've grown to 21 people, creating far more complex websites, applications and systems, and sometimes collaborating with external developers.

It's easy to say that the demands have changed radically.

The basics of Git

This won't be a complete guide to what Git is and how it works. The focus of this series will be our way of handling things. But I'll cover the most basic things just to make sure that you'll be able to follow along. If this section sounds like gibberish to you, it probably means that you're not a part of the target group, and may not be interested in the following posts.


Lets say you have a site where there are no bugs (yeah right) and there is no ongoing work. All of the files and their state is stored in a branch called master. Now, you're going to add a new feature to the site, an embedded Twitter feed for example. In order to isolate this work from the current state (the master branch) of the site, you can create a new branch for this new feature. All of the changes and additions that are related to the Twitter feed will be stored in the new branch which I'll be calling feature/twitter, for future reference.

If you were to check out (switch) to the master branch again, the Twitter feed would disappear. But if you check out the feature/twitter branch again, the feed will magically appear.


Lets use the example from the above scenario. When you first created the feature/twitter branch, there would be no changes to the code since it was created based on the master branch. But when you added the required code for the Twitter feed, this change would be reflected in the current state of the branch. Git would recognize a change to the relevant files, but since you haven't committed the change yet, there's no record of this change taking place.

When you've tested the new Twitter feed and verified that everything works, you would commit this change along with a message which indicates what you've done, e.g. "Added Twitter feed". This would mean that the change is stored in the current (feature/twitter) branch, and Git wouldn't see any other changes since every change has been committed.


When the Twitter feed has been thoroughly tested, it's time to add this to the current state of the site. Since the changes have been made in the feature/twitter branch and the current state of the site is still in the master branch, we'll need to make sure that the changes made in the feature/twitter branch get merged into the master branch.

A merge means that Git will take all of the commits that have happened in the feature/twitter branch, and apply the exact same changes to the master branch. This will make the Twitter feed available in the master branch as well.


A remote is a place where people will be able to merge their work together, in order to store it in a single place. This is used as the starting point for all of the developers that are working on the site. Since we've added a Twitter feed to the master branch just now, we want to make sure that all of the other developers would get access to it. This is done by simply pushing the master branch to the remote. And whenever the other developers want to get working on the site, they would pull the changes from the remote in order to get the Twitter feed.

Simple as that.

Different workflows

As mentioned earlier, there are a lot of different ways to work with Git. Every organisation should find a way that's suitable to their needs, in order to not overcomplicate things but still meet the demands for every project.

For instance, projects on Drupal.org follow a branching model where a branch represents a major release of the project. For a module, this would mean a branch named 7.x for the Drupal 7 version of the module, and an 8.x branch for Drupal 8. Releases are automatically created based on tags, which also should follow a naming convention, and dev releases are automatically created based on the last commit.

I won't cover any additional workflows, but please read this tutorial by Atlassian if you wish to get more in depth with the most common workflows.

How to learn Git

Altough there are great GUIs, like Tower, I really recommend the hardcore, terminal-way in order to really learn Git. It's easy to miss out on important things and to misunderstand the terminology of Git if you start of with a GUI. Trust me, it's worh the effort.

A really easy way to get going is to go through the step-by-step tutorial that's provided by Code School. It'll only take 20-30 minutes, and you'll get a good understanding of the basics.

In the next post, I'll cover the basics of our workflow and how we take advantage of branches.