Semanitc Commit Messages
Commit message format
It's crucial that all commit messages follow the semantic commit form not only to ensure the correct versioning but also to generate a clear and understandable changelog.
We use commitlint to lint commit messages according to these guidelines:
<type>(<scope>): <short summary> <TICKET-ID>] │ │ │ │ │ │ │ └─⫸ JIRA ticket ID (required) │ │ │ │ │ └─⫸ Summary in present tense. Lowercase and no period at the end. (required) │ │ │ └─⫸ Commit Scope (required) │ └─⫸ Commit Type: build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test <body> (optional) <footer> (optional)
Examples:
feat(ui): add 'outline' button variant [OS-1111] -- fix(accessibility): ensure all buttons are accessible via keyboard [OS-5678] -- chore(lint): specify allowed prefixes for ticket ids in commit message [OS-9999] -- fix(responsive): improve responsiveness of modals [OS-5631] BREAKING CHANGE: The responsiveness of modals has been improved. Projects utilizing the modal component might need a review and potential adjustments.
For more information about semantic commits, please refer to the Conventional Commits and Angular Commit Message Conventions.
Pull requests
As part of our adherence to semantic releasing, it is important to follow a specific commit message format. Currently, when we click on the merge button for the pull request, Bitbucket opens a merge commit message modal. We need to edit the commit message to meet the conventional commits format in order for the release to go through and the changes to be published successfully.
For example,
Let's observe the commit message auto generated by bitbucket for us, when we merge a pull request. It looks like something like below
Merged in bugfix/OS-2334-minor-bugs-from-angular-upgrade (pull request #11)
OS-2334 minor bugs from angular upgrade
- fix(ui): fixed autocomplete no results item text color [OS-2334]
- fix(ui): fixed checkbox ripple color [OS-2334]
- fix(ui): fixed tooltip BG color [OS-2334]
Approved-by: Edward Robson
Approved-by: Chirag Paryani
However, above doesn't follow the conventional-commits format. We must edit the above commit message to look like below
fix(ui): fixed autocomplete no results item text color [OS-2334] fix(ui): fixed checkbox ripple color [OS-2334] fix(ui): fixed tooltip BG color [OS-2334]
Note: Please ensure that all formatting elements, such as bullet points, are removed from the message for semantic release to work.
This flexibility allows us to have either multiple commits or just a single commit in the squash merge commit message, provided they all adhere to the conventional commit message format.
You may be curious about how the conventional commit approach handles multiple commits of various types such as fix, feat, BREAKING CHANGE, chore, etc in a single squash merge commit message. In this approach, the commit type with the highest significance is prioritized. Among multiple commits, the one marked as BREAKING CHANGE is considered the most crucial, followed by feat, fix, chore, and others. As a result, the version of the published npm package is determined based on this priority. If you need further clarification or understanding, please refer back to the section on Semantic Versioning and Release or reach out to one of your team members.
It is recommended to keep the number of commits per branch or pull request minimal. Having a large number of commits can make it difficult to track changes and can lead to confusion. It is best to group related changes into a single commit whenever possible. This helps maintain a clean and organized commit history, making it easier for others to review and understand the changes.
If you're on bitbucket right now, the internal links with markdown are broken, but you can try visiting those by using links below Conventional Commits Format Semantic Versioning and Release
Hot Tip
If you're curious about how your commit message will perform once merged, you can conduct a local dry run of the release. Start by checking out the master branch and performing a squash merge of your branch onto master, using the desired commit message. After that, execute the command npx semantic-release --dry-run to verify whether a new release will be published with the expected changelogs. Remember, it's important to reset your master branch when you're done.
Keep in mind, it's essential to utilize the dry run flag and reset the master branch prior to starting new tasks. If you're feeling uncertain, no worries at all, feel free to proceed with merging your pull request and ignore this hot tip! We're always here to assist in resolving any build issues with a proactive solution! 😄
see also :
