Dunkelheit

An Introduction to Git Etiquette

Git Etiquette is an interesting subject and one that I found myself having to teach my classmates often. Which I enjoyed because teaching is the greatest way to learn. (Apparently)

Quite simply it is the practice of standardising the way you manage your repo and how you communicate regarding things inside of the repo and generally for the purpose of making sure you don’t get conflicts, errors and other disasters that lead to development down time.

The way I like to teach Git Etiquette is to introduce a schema and then give examples of how to operate within this schema.

Schema

A typical schema that was used on team projects at University was the following:

b-bug-name          |   Bug branches
doc-document-name   |   Documentation branches
f-feature-name      |   Feature branches
master              |   Master branch
t-test-name         |   Testing branches

This allowed us to see at a glance what was going on in a branch without having to ask someone.

I would then give examples of how to create branches, switch to them and back, give proper commit messages and other basic Git usage. The hour or so it takes to teach all of this at the start saves you immeasurable time later and keeps everyone happy.

Semi-Automated Project Management

Next we made sure to use the GitHub issues tracker, personally I am not a fan of this but it was a reasonable compromise to make for the sake of the team’s comfort.

Merge and pull requests went through a two person verification stage to make sure we caught any issues before pulling them into the master branch. This was very effective. One developer would verify the contents of the commit and then escalate to the leader of his team or the project so that the users that could push to master was limited to those that were responsible for the project going smoothly.

This was an extremely effective means for us to keep everything flowing and smooth. With minor hiccups along the way when someone needed help with using Git as there are many people with zero experience of Git or similar software at University and not all Universities have classes on this subject.

Git Etiquette and You

There is a good chance that only some, perhaps none of the above will be perfectly applicable to your project(s). That’s a good thing, your schema and management rules must apply to the scope of your project after all. You may need more branch naming schemes than this, you may need more layers of verification. The important thing is to have a set of rules set out when you start so that events can flow into the desired workflow.