Skip to content

Branch and Commit Message Guidelines

Oskar W edited this page Jun 14, 2022 · 2 revisions

Naming convention

Just like any other bigger project we follow certain naming convention to make the gitflow more consistent and our codebase more maintainable for all contributors. Most of the variable naming is already checked by Jenkins, however there is also a branch naming convention as well as commit message guidelines.

Branch

In order to get your branch merged you need to follow our branch naming convention. The branch name is the ticket prefix just like the commit prefix. For the ticket CATROID-100 on Jira you just name the branch CATROID-100 without any further comments.

Commit

CATROID-<Jira-Ticket-ID> Short (60 chars or less) summary

More detailed explanatory text. Wrap it to 72 characters. The blank
line separating the summary from the body is critical (unless you omit
the body entirely).

Further paragraphs come after blank lines.

- Bullet points are okay, too.
- Typically a hyphen or asterisk is used for the bullet, followed by a
  single space. Use a hanging indent.

Before doing a commit, make sure to set the copyright in the file header to the current year if this is not the case. This can also be done during the commit flow of android studio on the right side under: -> before commit -> Update copyright

before commit settings

Rules of a great git commit message style

  • Separate subject from body with a blank line
  • Do not end the subject line with a period
  • Capitalize the subject line and each paragraph
  • Wrap the body at 72 characters
  • Use the body to explain what and why you have done something. In most cases, you can leave out details about how a change has been made.

Information in commit messages

  • Describe why a change is being made.
  • How does it address the issue?
  • What effects does the patch have?
  • Do not assume the reviewer understands what the original problem was.
  • Do not assume the code is self-evident/self-documenting.
  • Read the commit message to see if it hints at improved code structure.
  • The first commit line is the most important.
  • Describe any limitations of the current code.
  • Do not include patch set-specific comments.

Details for each point and good commit message examples can be found on https://wiki.openstack.org/wiki/GitCommitMessages#Information_in_commit_messages

Things to avoid when creating commits

  • Mixing whitespace / formatting changes with functional code changes.
  • Mixing two unrelated functional changes.
  • Sending large new features in a single giant commit.

Example

CATROID-42 Order XStream XML fields by annotation

The new XStreamFieldKeyOrder annotation provides an easier way to define
a custom field order in the XML file.

Only serialized (!static and !transient) fields have to be specified in
the annotation now. If not specified, the CatroidFieldKeySorter will
throw an exception when…

Resources

http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
https://wiki.openstack.org/wiki/GitCommitMessages
http://chris.beams.io/posts/git-commit/