GIT Commit Format

Writing a meaningful message for reasonably sized commits is important to create a clear story about the history of your project. Like in so many other things, being consistent in commit messages produces compound results over time!

All your commit messages must have the following format:

[Type] [Requirement ID]: [Short summary - active present tense phrase] - [Issue Action]
[Body - longer explanation of the changes, especially how they might impact your teeammates]
Collaborators: [names of students who directly helped to design or develop this code]

For example:

Feature BREAK-03: update ball to bounce off multiple blocks

Feature BREAK-03: add block disappears when hit by ball - closes #3 The block is removed from both the scene and the list of blocks.

Refactor DESIGN-01: add Ball class to allow for multiple balls in game

Data: add second level design Uses format where 0 is empty and numbers represent different types of blocks.

Test CELL-01: add test for glider configuration Collaborators: Robert Duvall

Type

The type field says that the change was made for a particular reason, and must be one of the following:

• Feature: change which adds or updates functionality
• Test: change which adds or updates test code
• Fix: change which fixes found bug and tests specifically for that issue
• Refactor: change which improves the design rather than the functionality
• Data: change which adds or updates data or configuration files
• Doc: change which primarily comments code, adds or updates Markdown files
• Config: changes which adds or updates project configuration files
• Merge: changes which resolve a merge conflict
• Other: change which you do not feel fits into one of those categories

Requirement ID

The requirement field refers to the project specific requirement as described in the requirements glossary, starting with either DESIGN-XX for refactorings or PROJECT-XX for new features, tests, and bugs.

Note, Data, Doc, and Config do not need to reference a requirement.

Short Summary

The summary field provides a succinct imperative, present tense description of the change (i.e., "change" not "changed" nor "changes").

As Chris Beams notes in his article about commit messages, the summary should be able to complete the following sentence:

If applied, this commit will… 

Issue Action

Optionally, the issue field takes action on a specific project Gitlab Issue, either a complete Functional Requirement or team created sub-task, by referencing the issue by number (#NUM) using one of Gitlab's action words.

Body

Optionally, the body field should start on a separate line and be worded like the summary, but explain the motivation for or additional details about the change.

Collaborators

Optionally, the collaborators field provides the name of students who directly contributed to this change, such as with a detailed design discussion or helping develop the code using Pair Programming or helping with debugging.