Commitment Issues – Git Branching made easy

Imagine a software development world without Git & Git Branching. Unthinkable – kinda. Linus Torvalds’ version control system is used in companies, universities and open source projects alike and it’s easy to get used to its powerful but simple approach. Still, everyone likes a different workflow, which is why teams have to adjust and agree on something to work as a team. A short guide to Git Branching – Commitment Issues gone.

Git Branching

Teamwork meets source code

“I am THE developer. All the others are scrubs. My code is poetry. My programs are the law.”

What sounds like brainwashing should show you a problem in software development: Developers love to work on their own. So how do we gather code from all contributors? How do we enable efficient and effective collaboration with source code? Git is the answer and Git Branching the liberating workflow.

Git Branching

This blog post doesn’t cover the basics of Git, as this would clearly blow up the scope by…hmm…let’s say a sextillion. If you want to know more about Git and its advantages, check out the official website:

Git Branching

A branch usually stands for a specific development phase, code stability or a defined feature. If you are using Git, you probably work in different branches and therefor use Git Branching already to some extent.

Vincent Driessen suggests a fantastic branching model in one of his blog posts. We are going to use and simplify this model for smaller and medium sized teams.

Okay, so the development gets divided in different branches. The most important and the most common ones are master and develop(ment). These main branches exist during the whole lifetime of the project. There are also short-lived ones for single features, hotfixes and releases, which usually only live until they get merged back into their parent branch.

This branch consists solely of stable code – production-ready code that works and passes all the tests. Release versions are tagged within the master branch.

develop reflects the current development and includes finished features and bugfixes for the next release (nightly builds are taken from this branch). If the code is stable and ready for release it gets merged back into the master branch and tagged for release.

New features should be developed in separate feature-branches, which will be merged back into the develop branch, once they are completed.

Urgent bugfixes (hotfixes) can be handled in hotfix branches and merged back into the develop– and master branches. Of course they could be developed in the develop branch, but this branch isn’t necessarily ready for production, so a hotfix should probably get its own hotfix branch.

In order to prepare for a new release you can use release branches to make final fixes and changes needed for the new version number. Similar to hotfixes this branch gets merged into master and back into develop.

From now on you shall be called …

Branches should follow a consistent naming schema. Ideally a short, hyphenated name, which best describes what’s done in this branch. If you are using JIRA for agile management, you can even include issue/task numbers to create a link between them.

Examples for branch names would be:

  • master
  • develop
  • feature/pdf-creation
  • hotfix/XYZ-43-responsive-layout
  • feature/XYZ-99
  • feature/a-very-long-description-no-really-it-is-not-even-funny

This approach makes it easier to identify branches, which in turn makes it easier to collaborate as a team of software developers. In addition, it also helps the project lead or SCRUM masters to know what’s going on without having to dig into the code changes themselves and to have a better overview.

Depending on the project and the size of the team you could also add in a little magic of pull requests, to allow for easy code reviews.

Commit & Push

Project Lead to Developer: “We are still waiting for feature XY! Did you finish it by now?”
Developer: “Of course, I finished it before my vacation when I was doing home office!”
Project Lead browses through the repository, without finding any changes: “Did you push your changes?”
Developer: “Uhm, I guess I forgot to…”

Now we are stuck as feature XY rests peacefully on the developer’s home computer. Great.

As you can see, committing and pushing your changes on a branch are crucial when it comes to collaboration in software development. With git commit and git push you share your code with your team in a structured and reversible manner.

In case of fire, git commit & git push

by Marco Leong is licensed under CC BY-NC 4.0

As with branches, commits should also follow a standardized naming schema, so even non-technical persons can immediately see what was done.
In order to achieve this, the first line of a commit message should summarize the changes in a short and precise way, using a specific language and consistent keywords like added or removed.

Examples for commit messages (1st line):

  • fixed slider pagination
  • XYZ-56 added initial printing feature
  • XYZ-57 XYZ-58 changed colour scheme, removed log files
  • fix
  • XYZ-59

Of course you and your team will need some time to get used to these guidelines and the proposed workflow, but in return you will be rewarded with a consistent structure and the ability to work as a team without messing up code and creating a ruckus in your repository.

Further Reading:

Vincent Driessen’s blog with more details about his proposed model
Git Cheat Sheet
Git GUI Clients
.gitignore Templates

The used images are licensed under CC BY-NC-SA 3.0 and are part of the book “Pro Git“.