Getting git right

On the 27th November, after the last Mrgn of the year, I spent the afternoon at the Getting Git Right event organised by Atlassian (makers of JIRA, Confluence, Stash, Bitbuckets and some other developer tools we have used before at asquera) and Codecentric.

As a project manager I don’t get to use Git in my everyday work, but it is important for my work that I understand the tools the developers use, the advantages of using them vs using others, and the best ways to set them up to speed up our work, save their time, and make sure communication flows.

The evening featured a talk about what git is, how it is better than other alternatives, how it helps development, and how the Atlassian tools handle it.

Introduction

Git is a version control system used by development teams to track changes to their work - mostly code but sometimes also documentation.

There are other version control systems out there - think of the changes history we can find in many text editors or content management systems, or more specifically in systems such as subversion. Git was created by Linus Torvald for the Linux Kernel in 2005, as a solution to his desire of using a version control system that was free, fast, and scalable.

Git is a distributed version control system. This means everyone has his / her own copy of the repository and development happens locally, in your machine, except pull and push. The repository contains the whole history of changes. To start using git in a project, you first must either initialise a new repository or clone an existing one - a folder for code, where it can be stored and retrieved. In order to be able to collaborate with other developers, you need to make the repository available on a remote location, where others can clone your repository. From then one, you’ll all have a connection to a shared code storage.

Git is also non-linear, as work happens in branches that are created, worked and then merged back to the main branch (e.g. master). This lets different team members work using the existing code, but making sure their changes do not interfere with others and providing safety against intentional or accentual corruptions of the code.

Git workflows

Branching is very cheap in git, so creating one branch per feature is advised to improve safety and ease progress tracking. using different branches lets developers and us project managers easily understand what’s the status of a feature, and it is specially useful for those who work with Agile methodologies, when a ready to ship product is needed at the end of each sprint, as it lets you easily take the master branch and launch it, while developers can keep working on their feature branches. A characteristic of a feature branch is to allow one or more developers to group a set of dependent changes and makes reviews a lot easier. This separation of work in branches allows teams to implement all possible workflows.

Inside of each branch, developers track their progress using commits. A commit is a record of a change in the code that is stored in your local repository. It records a snapshot of the current state of the code (as opposed to the differentials or deltas used by other version control systems) and lets developers add an explanation of the changes made.

This is how a commit looks like:

commit caf0fc848cbe08a02cea4977ffa9c8e92c3e5e6f
Author: Cristina Santamarina <hola@cristinasantamarina.com>
Date:   Tue Nov 25 16:26:53 2014 +0100

    add table and radio buttons to guestsList

If you dive deeper into it, either using the terminal or using software apps made for it, you can see what was added or removed in each specific commit. This provides a great audit trail as well as the possibility to reverse changes if needed.

As you can see, commits have information about the person & a commit message. This is entered by the developer at the moment of doing the commit, and it provides information to understand what happened without having to read the code - a very nice thing to have for project managers, business people reviewing the repository - or developers in a hurry.

Git, as said above, is a distributed version control system. This means commits are stored locally, in each developer’s machine. To share commits with the rest of the team, developers need to push their code to the remote repository. When this push is made, the code will be made available to all the other developers and the branch will be ready to merge. Other developers need to pull those changes to their respective local repository.

This may be fine in small teams working in their free time projects, but most serious software development requires some kind of quality assurance process. And git also has a way of handling this: pull requests.

A pull request is a way to submit contributions. When sending a pull request, a developer is asking to have his or her work added to the main branch.

When a developer finishes a feature, he or she pushes the code and creates a pull request. When this code is pushed, developers have the option to share it with specific members of their team (called reviewers) who can see the changes in the code, ask questions or make modifications, before they OK it to be merged.

Different projects and different teams need different workflows, so there are many different combinations of these actions and team policies. We looked at a couple of them in the Getting Git Right session, but the one I like the most and I’d like to share with you is gitflow.

Gitflow proposes two main branches in the origin (the remote copy of the repository where all the work from all the developers ends). One, master, always contains finished, working software, and is ready to be deployed to production at any time. The other branch, develop, contains the work in progress for the next release - and any time the teams consider that it has reached a mature state, it is merged to origin/master and tagged with a unique identifier: the version number.

On top of these two branches, developers are encouraged to create more - as we said branching is cheap in git, so we can have as many branches as we need for features, hot fixes, releases… They branch from the develop branch. Using branches can minimize the risk that the developer’s work does not interfere with another's one work and will allow team members to easily understand the progress of the collective work.

Multiple branches and gitflow can seem complicated at the beginning, both for developers and managers, but when implemented right can give your team superpowers.

Git for happy developers

The last part of the Getting Git Right talk was about how git makes happy developers, and how Atlassian tools, such as JIRA, Stash, Bitbucket, and all the integrations among them push this happiness effect even further. All the Atlassian tools work together and let you do things like automatically name a branch after the user story reference, limit the access to a repository to a specify person or group, or automate the code review process.

Giving your developers the tools they need to make their job and helping them find the best workflows will not only make them happier at work but will also give you an easier way to oversee the progress of the project, spot failures early, and increase your efficiency and effectiveness.