Hello team,
We introduce commit conventions in our organizations that will help us automate many release tasks - automatically collect commits into changelog, determine semantic version of new releases, and collect commits into release notes.
We will follow Conventional Commits https://www.conventionalcommits.org/en/v1.0.0/ format, it requires you to provide commit type and optional `!` after the commit type to indicate that your commit introduces a breaking API change. You can find more information at Conventional https://linux-system-roles.github.io/contribute.html#conventional-commits-format Commits format https://linux-system-roles.github.io/contribute.html#conventional-commits-format section on our site. It also generally improves commits hygiene in our org.
A correct commit format will be verified by a CommitLint GitHub Action, it will verify each commit in the PR to follow conventional commits format, and also the PR title to follow the format for consistency. The action won't be able to verify if we provide a correct commit type and if we indicate a breaking change correctly, so we must pay special attention to it.
One concern is with the *Squash and merge *strategy that PRs currently use. When you click the *Squash and merge* button in GitHub UI, it lets you manually modify the resulting commit and push it to main right away. This is a subject to human error because the resulting commit goes straight to main, and in the case of a typo we would need to force push to main to fix it. It is best to move to a *Rebase and merge *strategy instead to ensure that all commits pushed to main have passed CommitLint checks. This is not ideal but the pay off is huge.
Let me know if you have any concerns or questions.
Thank you