Skip to content

Latest commit

 

History

History
95 lines (78 loc) · 3.49 KB

commit_message_format.md

File metadata and controls

95 lines (78 loc) · 3.49 KB

Commit Message Guidelines

Short (72 chars or less) summary starting with prefix 

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).

Write your commit message in the imperative: "Fix bug" and not "Fixed
bug" or "Fixes bug." This convention matches up with commit messages
generated by commands like git merge and git revert.

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.

Example for a commit message

feat: add auto creating time slots in database

[15] This function replaces a manual creating time slots.
It will be called from anoter function that decides whe to call.
I takes 3 params: 
- a daily slots pattern (list of time slots)
- amount of monthes from today to get the day slot should be created in
- cursor of connected dataabase
Than checks if slots for the day exist, 
if not creates slots, checks htem, returns true.
if exist returns true.
if failed to create returns false.

It logs all atempts in database before returning.

A properly formed git commit subject line should always be able to complete the following sentence

If applied, this commit will <your subject line here>

Use folowing prefixes for summary:

db: - when data base related code changed/adde that is not part of app logic debug: - when code added for debugging docs: - when README, files in /docs/ or usefull comments added (edited) feat: - when some new features added fix: - when fixing or deleting commented and unused code git: init: - the first commit refactor: style: - when styles only are edited test:

Rules for a great git commit message style

  • Separate subject from body with a blank line
  • Do not end the subject line with a period
  • Use the imperative mood in the subject line
  • Wrap lines 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

References in commit messages

If the commit refers to an issue, add this information to the commit message header or body. e.g. the GitHub web platform automatically converts issue ids (e.g. #123) to links referring to the related issue. For issues tracker like Jira there are plugins which also converts Jira tickets, e.g. Jirafy.

In header:

[#123] Refer to GitHub issue…

CAT-123 Refer to Jira ticket with project identifier CAT…

In body:

…
Fixes #123, #124

Sources