Member-only story
Code Commit Guidelines using Conventional Commits
Let’s explore pre-commit a more structured way to commit history and how to make it easier for people to contribute to your projects
In order to keep commits aligned across all repositories, we should use the Conventional Commits specification.
The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of it.
Conventional Commit makes it easier for people to contribute to your projects, by allowing them to explore a more structured commit history.
Commit
Each code commit should have some basic details about the commit and the ticket description. It will be easier to track the ticket from commit. It will be easier for team members to understand and follow the pattern if each team member is following the same way.
Pull Request
Each PR should contain ticket details and the title of the PR. It should also contain the type of ticket so team members can check if it was a feature/enhancement or bug fix.
In general, the commit message should be structured as the following pattern:
<type>[optional scope]: [REFERENCE-1234]
<description>
[optional body]
[optional footer(s)]Real-world examples can look like this:
chore: [PRJ1-123] run tests on jenkins ci
fix(server): [PRJ2-1234] send cors headers
send CORS headers by reflecting the origin header in the request
feat(blog): [PRJ2-1234] add comment sectionExamples
Commit message with scope, description, and breaking change footer:
// without scope
feat: allow provided config object to extend other configs
BREAKING CHANGE: `extends` key in config file is now used for extending other config files
// with scope
feat(lang): add Polish languageCommit message with multi-paragraph body and multiple footers:
fix: prevent racing of requests
Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest…
