FAQ
We recommend that you proceed as if you’ve already released the product. Typically somebody, even if it’s your fellow software developers, is using your software. They’ll want to know what’s fixed, what breaks etc.
While the emojis provided in the Conventional Emoji Commits list offer a guideline, you can choose your own for custom scopes. However, be aware that using custom emojis might cause automated tools to malfunction, as the data extraction of these emojis could potentially fail. It's best to be consistent across your project. If you believe a specific emoji should be added to the standard list, consider submitting a PR.
Go back and make multiple commits whenever possible. Part of the benefit of Conventional Emoji Commits is its ability to drive us to make more organized commits and PRs.
It discourages moving fast in a disorganized way. It helps you be able to move fast long term across multiple projects with varied contributors.
Conventional Emoji Commits encourages us to make more of certain types of commits such as fixes. Other than that, the flexibility of Conventional Emoji Commits allows your team to come up with their own types and change those types over time.
🩹 fix
type commits should be translated to PATCH releases. ✨ feat
type commits should be translated to MINOR releases. Commits with 🚨 BREAKING CHANGE
in the commits, regardless of type, should be translated to MAJOR releases.
We recommend using SemVer to release your own extensions to this specification (and encourage you to make these extensions!)
Prior to merging or releasing the mistake, we recommend using git rebase -i
to edit the commit history. After release, the cleanup will be different according to what tools and processes you use.
No! If you use a squash based workflow on Git, lead maintainers can clean up the commit messages as they’re merged—adding no workload to casual committers. A common workflow for this is to have your git system automatically squash commits from a pull request and present a form for the lead maintainer to enter the proper git commit message for the merge.
Reverting code can be complicated: are you reverting multiple commits? if you revert a feature, should the next release instead be a patch?
Conventional Emoji Commits does not make an explicit effort to define revert behavior. Instead, we leave it to tooling authors to use the flexibility of types and footers to develop their logic for handling reverts.
One recommendation is to use the revert
type, and a footer that references the commit SHAs that are being reverted:
revert: let us never again speak of the noodle incident
Refs: 676104e, a215868