This is how I git commit

Well, now I’m going to tell you what are the conventions (read: the ones I remember in this moment) that I used or still use for my commit messages on git.


Please remember to use your own conventions only when you’re working on your own repositories.

Read the commit history and please understand and follow the conventions that the owner of the repository you’re contributing is using. It’s a matter of respect.

Generally talking

When there’s code that needs to be explained, a description is of course added.

Usually I use just git commit, so that the text editor is opened and I’m forced to respect the number of characters in every line.

The first commit message

The first commit message I use for a new repository is “Initial commit”.

For large projects or the ones based on frameworks, the first commit contains as less code as possible, while for little gems the whole code is committed in one shot.

Some times ago I was using “first commit” and when I was a kid “Hello, world” as well. While the former would be fine too (maybe capitalized), the latter is lolnope.

The paste tense

Like “Fixed a bug related to df”. I used this style in the very beginning.

By following this style, commit messages are usually long and anyway go against the “official” guidelines.

The imperative way

For example “Ignore already downloaded episodes”.

Well, this is the one I used most. It’s generally the most used convention, and this is why I adopt it for projects where many people are involved (like in the Honeypot and Bugree codebases).

Above the “standard” messages for the usual daily stuff:

  1. Add a new file: “Add .gitignore
  2. Release a new version: “Bump version
  3. Implement new features or do refactoring: “ Implement Notifu”

The way of meh.

No, it’s not really mine since meh. is actually this guy. I just adopted it.

This is a great way to manage your commit history properly since it forces you make clear and descriptive message to very small and simple commits.

When your codebase is organized in many components this way really shines.

It’s not really easy following it at the very beginning, but when you enter in the correct mindset, even the way you write your code starts to change.

Probably this is not really suitable if you’re working with people who really don’t care writing proper commit messages or if you want to deliver a bunch of changes in one shot without caring about them.

Basically the whole commit message is lowercased (I started doing this only recently though), the mood is imperative and there is a colon (“:”) that splits the name of the file without its extension (and the eventual “_spec” or “_test” as well) by the actual “action”.

But let’s the commits talk for us:

1. Add a new file: “Add .gitignore

2. Release a new version: “version: bump to 0.4

3. Add new features or change some code in a single file: “rakefile: run `bundle install` before building the gem”, “dumper: split warning message in two lines

4. Add new features or change some code in more than in more than one file: “DBMS: add test for MySQL and PostgreSQL” (in that case writing “spec/DBMS: add …” would have worked even better btw) or “*: refactor way to handle something”

What about merging branches?

I usually submit a new pull request and then merge the branch in GitHub clicking on the green button to automatize the process, or otherwise, in terminal, “git merge --no-ff”. In this way we always keep the reference to the original pull request in our commit history.

There are cases, by the way, when I need to do some stuff in another branch (that no one else will touch) because the code must not reach the master branch until the merge. In this case, instead of submitting a pull request, when I’m done with the branch, I merge it rebasing it against the master branch so that the commit history of the latter remains clean and there are no clues about the existence of that branch. It’s something that I use really few times and do not really suggest, anyway (I’m often paranoic and I prefer pushing the WIP somewhere).

In any case, after the merge the branch is deleted.

Remember to keep your branch list clean with only active branches!

*HUGE thanks to alfateam123 for checking this article!