.gitmessage

# ---------------- 50 characters ----------------|
# Use the header budget: target 45-50 characters including <area>: .
# ------------------------- 72 characters -------------------------|
# Wrap the body and footer at 72 characters.

# Header
# <area>: <action> <specific summary>
#
# area: required noun for the affected module, configuration area, or
#       repository area.
#       examples: nvim, shell, git, tmux, vscode, docker, rust, nodejs,
#                 python, link, docs, repo
# action: clear change word after the colon.
#         examples: fix, feat, add, update, remove, refactor, test, docs
#
# Examples:
# git: update message template for commit guidance
# shell: add alias for project navigation
#
# Summary:
# - target 45-50 characters for the full header, including "<area>: "
# - revise headers under 40 characters unless the change is tiny or
#   mechanical
# - make the concrete change understandable from the header alone
# - name the changed behavior, guidance, file role, or review impact
# - use imperative present tense: "change", not "changed" or "changes"
# - do not capitalize the first letter
# - no period at the end

# Common actions
# build: change build systems or external dependencies
# chore: make maintenance changes that do not fit another action
# ci: change CI configuration files and scripts
# docs: change documentation only
# feat: add a new feature
# fix: fix a bug
# perf: improve performance
# refactor: change code without fixing a bug or adding a feature
# remove: remove behavior, files, dependencies, or guidance
# revert: revert a previous commit
# style: change formatting, whitespace, or other non-meaningful style
# test: add missing tests or correct existing tests
# update: change existing behavior, files, dependencies, or guidance

# Body
# Write a body by default. Explain why the change is needed and what
# changed, and any behavior or review impact. Compare old and new
# behavior when it clarifies impact.
# Omit the body only for obvious typo, formatting, or mechanical changes
# where extra explanation would add no review value.
# Leave one blank line between the header and body. Multiple body
# paragraphs are allowed.

# Footer
# Use footers for issue references, breaking changes, deprecations,
# reviews, and reverts. Start footers one blank line after the body, or
# one blank line after the header when there is no body.
#
# Fixes #123
# Closes #123
# Refs: #123
# Reviewed-by: Name
#
# BREAKING CHANGE: <summary>
# <description and migration notes>
# Do not use ! in the header for breaking changes.
# BREAKING-CHANGE: <summary> is also valid, but prefer BREAKING CHANGE:.
#
# DEPRECATED: <what is deprecated>
# <recommended update path>

# Revert commits
# <area>: revert <header of reverted commit>
#
# This reverts commit <sha>.
#
# Explain why the revert is needed.