Using GitHub for the first time has a steep learning curve. To use GitHub with a team is a whole different ball game. Here are some best practices I’ve come to know during my team projects.

Published on 26 June 2017 by Danny de Vries

Using GitHub as a team — 4 min read

Using GitHub for the first time has a steep learning curve. To use GitHub with a team is a whole different ball game. Here are some best practices I’ve come to know during my team projects.

Throughout the various OSS projects that I contributed to one thing always takes up more time than I expect. Setting a Git(Hub) standard for working on a repository (or repo as the cool kids say it). Below are some best practices that really helped me along the way.

[https://twitter.com/thepracticaldev](https://twitter.com/thepracticaldev?lang=en)https://twitter.com/thepracticaldev

Project your branches

The first thing that prevents headaches in the future is to protect the master branch and make a develop one right away. It disables force pushing and prevents branches from being deleted. A great way to protect you’re project and make sure that you don’t have to 🚑 hotfix anything if you use continuous integration for example.

Consistent branch naming

With the master branch protected contributors can’t push straight into master. They have to use branches and make pull requests. Coming up with a naming convention for the branches is very helpful. One of the things is to use prefixes:

In a quick overview you can see what each branch is for and they have consistent naming.

Pull requests

Make sure PR’s can’t be merged without a required review. If you protect a branch you can also enable Require pull request reviews before merging. Every PR that comes in has to be reviewed by another contributor.

So, merging is blocked by default. A contributor has to manually navigate to the PR and hit review changes. You then can either:

A great way to get a quick quality check before the code get merged.

Commit messages

Oh god, commit messages. Always a painful topic to talk about. Everyone has a personal / preferred way to do it. Chris Beam has written a great post about this in 2014. It are some general rules but most people find them acceptable.

You should definitely read the full post.

Here are his seven golden rules:

  1. Separate subject from body with a blank line

  2. Limit the subject line to 50 characters

  3. Capitalize the subject line

  4. Do not end the subject line with a period

  5. Use the imperative mood in the subject line

  6. Wrap the body at 72 characters

  7. Use the body to explain what and why vs. how

Ideally your commit title would look like this:

Add styling for navigation bar

Usually these rules are outlined in the contributing.md and examples are given.

Plan your commits

Guilty as charge of commiting a large blob of code. But, planning your commits is also a good strategy to keep yourself in check. Before you go straight into building that feature try to break the feature down into small steps. Each step then represents a commit. Here is a quick little post on dev.to about this.

Gitmoji

Last but not least the holy grail of commit messages. GITMOJI 🎉🦄🔥. Made by Carlos Cuesta Gitmoji has to be one of my favorite CLI tools.

Gitmoji is an initiative to standardize and explain the use of emojis on GitHub commit messages.

It’s great cause it forces you to categorize your commits and even better, in the history you can easily spot the core of each commit and recognize it by it’s emoji.

You can use Gitmoji from the command line by installing it globally.

npm i -g gitmoji-cli

in the project you want to use Gitmoji type:

gitmoji -i

Gitmoji dialog in HyperTerm.Gitmoji dialog in HyperTerm.

From now on every git commit (or gc for the oh my zsh users out there) pops up the gitmoji dialog and before you can write you’re title you have to pick a gitmoji.

Coming up with a consistent GitHub standard and flow may take some time but it’s worth it in the long run.