Making good commits

How to write good commits

You should only commit changes that are contextually related, that is your changes should be grouped in a logical way. Before pushing, you can squash your commits (see here for an example).

Commit messages

Your commit messages should be descriptive, as they will appear on the CHANGELOG.rst file. It should look something like this (based on this):

The first 50 characters are used for the commit summary (A blank line, no text here) The next section can take up to 72 characters It probably makes sense to split them into smaller sentences This section contains a more detailed description of your commit Why something was added or removed and what was changed or fixed Which files or packages were involved (if there are too many, your commit is too large) (Another blank line) Bugs fixed: #1234 Implements: name_of_package

Examples of good commits

Sometimes one line is enough, as long as it provides enough information:

Remove deprecated functions from mcr_object_recognition

Some other times, a little more context is needed:

Replace topological map nodes with polygons

Old version was using a standard string as a node
Nodes are now polygons which represent the rooms in the arena
This simplifies the way we check if a pose is inside a room
and the way we associate data.
Changes:
* topological_map_ros

Fixes #3

You can read more about how to write commit messages here and here.