Differences between revisions 1 and 6 (spanning 5 versions)
⇤ ← Revision 1 as of 2013-05-20 19:52:50 →
Size: 141
Editor: SamatJain
Comment:
← Revision 6 as of 2021-04-09 08:03:41 → ⇥
Size: 5024
Editor: SamatJain
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:

== 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 🛠️ config : Configuration change, e.g. modify a default.
 * 🌐 or 💬 i18n or l10n: Internationalization, localization, or translation addition, fix.
 * ♿ a11y: Accessibility.

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, e.g. comments. Subset of refactor.
 * 📚 docs: External documentation. 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.

Other:

 * 👌 review: Change from code review.
 * 📈 or 📡 telemetry, analytics, metrics, or logging
 * 🔊 log
 * ➖ removal
 * ➕ addition
 * 🔖 bookmark, tag
 * 📖 metadata
 * 📇 metadata or index
 * 💡 idea, comment, etc
 * 👕 lint
 * 🚑 or 🔥 hotfix
 * 💩 shitcode, needs refactor
 * 💥 breaking-change
 * 👥 contributor or sponsor update
 * 🍒 cherry-pick'ed commit
 * ☸️ k8s
 * 🐋 docker or container
 * ✅ Add but not ❌ Added

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

 * init
 * runner
 * watcher
 * config
 * web-server
 * proxy

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

 * 50c soft limit, hard limit of 70c
 * Uses imperative, present tense. "add" vs "adds" or "added", "fix" vs "fixes" or "fixed".
 * Do not end with period

<body> should:

 * 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 [[https://git-scm.com/docs/git-interpret-trailers|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.
 * `BREAKING-CHANGE: ${description}` to describe this commit breaks previous behavior/interface.


See also:

 * [[https://karma-runner.github.io/6.3/dev/git-commit-msg.html|Karma Git Commit Msg]]
 * [[https://365git.tumblr.com/post/3308646748/writing-git-commit-messages|365Git: Writing git commit messages]]
 * [[https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html|tbaggery - A note about git commit messages]]
 * [[https://sparkbox.com/foundry/semantic_commit_messages|Semantic Commit Messages]]
 * Emoji was taken from [[https://github.com/folke/devmoji|folke/devmoji]] and [[https://gitmoji.dev/|gitmoji.dev]]
 * [[https://chris.beams.io/posts/git-commit/|How to Write a Git Commit Message]]

Good examples:

 * [[https://github.com/eslint/eslint/commits/master|eslint commit history]]

== Semantic Branch Names ==

https://gist.github.com/seunggabi/87f8c722d35cd07deb3f649d45a31082

 * feature/: New feature
 * bugfix/: Bug fix
 * docs/: Documentation change
 * style/: Style change
 * refactor/: Refactor
 * test/: Adding tests, refactoring tests, etc.
 * chore:/ Chore

Git Commit Message conventions for AngularJS

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 🛠️ config : Configuration change, e.g. modify a default.
  • 🌐 or 💬 i18n or l10n: Internationalization, localization, or translation addition, fix.
  • ♿ a11y: Accessibility.

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, e.g. comments. Subset of refactor.
  • 📚 docs: External documentation. 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.

Other:

  • 👌 review: Change from code review.
  • 📈 or 📡 telemetry, analytics, metrics, or logging
  • 🔊 log
  • ➖ removal
  • ➕ addition
  • 🔖 bookmark, tag
  • 📖 metadata
  • 📇 metadata or index
  • 💡 idea, comment, etc
  • 👕 lint
  • 🚑 or 🔥 hotfix
  • 💩 shitcode, needs refactor
  • 💥 breaking-change
  • 👥 contributor or sponsor update
  • 🍒 cherry-pick'ed commit
  • ☸️ k8s
  • 🐋 docker or container
  • ✅ Add but not ❌ Added

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

  • init
  • runner
  • watcher
  • config
  • web-server
  • proxy

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

  • 50c soft limit, hard limit of 70c
  • Uses imperative, present tense. "add" vs "adds" or "added", "fix" vs "fixes" or "fixed".
  • Do not end with period

<body> should:

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

  • BREAKING-CHANGE: ${description} to describe this commit breaks previous behavior/interface.

See also:

Good examples:

Semantic Branch Names

https://gist.github.com/seunggabi/87f8c722d35cd07deb3f649d45a31082

  • feature/: New feature
  • bugfix/: Bug fix
  • docs/: Documentation change
  • style/: Style change
  • refactor/: Refactor
  • test/: Adding tests, refactoring tests, etc.
  • chore:/ Chore

SamatsWiki: CodingStyle/Git (last edited 2024-08-11 23:15:11 by SamatJain)