CodingStyle/Git - SamatsWiki

Conventional Commits format

<type>(<scope>): <subject>

<body>

<footer>

Where:

<type> is one of:

External-facing stuff, important to publish to users.

✨ or ⭐ or 💎 feat or new: New feature. Correlates to MINOR in Semantic Versioning.
- feat: add beta sequence
🐛 or 🐞 fix: Bug fix. Correlates to PATCH in Semantic Versioning.
- fix: remove broken confirmation message
🔒 security: Security-related fix, i.e. important to highlight in changelog.
⚡ perf: Change that improves performance. Sometimes a subset of refactor.
⚙️ or 🛠️ conf: Configuration change, e.g. modify a default.
🌐 or 💬 i18n or l10n: Internationalization, localization, or translation addition, fix.
♿ a11y: Accessibility.
🔊 log: Logging or printing-related added.

Internal repository-related:

🎉 initial: Initial commit of something, may not yet work.
⏪ revert : Revert of previous behavior, fix, or feature
✅ or 🚨 or 🧪: test: Adding new test or making changes to existing test
- test: ensure Tayne retains clothing
🔗 deps: Add, upgrade, or anything to do with an external dependency.
🔀 merge: Merge from another branch.
🚧 wip: Work-in-progress.

Internal changes, not user-facing.

🔧 chore: Code change that external user won't see and does not impact a feature (e.g. change to .gitignore file)
- chore: add Oyster build script
👷 ci: CI-related change, subset of chore.
- 💚 ci : Fix CI
📦 build: Build related changes (e.g. cmake, Broccoli, grunt). Subset of chore.
🚀 deploy or release: New version, snapshot, or deploy.

Refactor-related, i.e. does not add new features.

♻️ or 🔨 or 🛠️ refactor: A code that neither fix bug nor adds a feature. (e.g. semantic changes like renaming a variable/ function name)
- refactor: share logic between component1 and component2
✏️ comments: Internal documentation not otherwise exported, e.g. comments. Subset of refactor.
📚 docs: External documentation. Includes API documentation (docstrings, doxygen). Subset of refactor.
- docs: explain hat wobble
🎨 style: Style change, like improving structure or formatting. Subset of refactor.
- style: convert tabs to spaces
- style: format w/ black
🚚 rename: Move files. Subset of refactor.
🗑 remove: Remove deprecated code no longer used. Keep as a separate commit to make it easy to revert. Subset of refactor.
👕 lint: linting, typing, casting fix. Subset of refactor.

Other:

<scope> refers to the module or component. Examples:

<subject> is the first line of the commit message, and:

50c soft limit, 70c hard limit
Uses imperative, present tense. "add" vs "adds" or "added", "fix" vs "fixes" or "fixed".
Do not end with period
Finish this sentence: If applied, this commit will ${subject}

<body> should:

Focus on WHY and WHAT, not on HOW.
Includes motivation for the change, and contrasts previous behavior/implementation vs new behavior/implementation
Describe what the commit will do, not what you did.
Wrap at 72c.

<footer> should:

Be one per line, and follow the git trailer format. That is, each line is a key–value pair, separated by either :<space> or <space>#.
Closes #${BUG_NO}, e.g. Closes #123 if the commit closes an issue in your issue tracker.
Fix #${BUG_NO}, e.g. Fix #123 if the commit closes an issue in your issue tracker.
BREAKING-CHANGE: ${description} to describe this commit breaks previous behavior/interface.
Signed-off-by, Acked-by, Cc, Reported-by, Tested-by, Reviewed-by as described by Gerrit, based on Linux' SubmittingPatches guide.
See-also: