The usage of semantic commit messages in our code makes it easier to identify commits and what was worked on; it's critical to maintain the pattern across the team. I invite you to learn a bit more on how to create nice semantic commits messages and bookmark this article to show your team :)
To ensure consistency throughout the source code, keep these rules in mind as you are working:
- All features or bugs must be tested by one or more specs (unit tests)
Each commit message consists of a header, a body and a footer. The header has a special format that includes a type, a scope and a subject:
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
The header is mandatory and the scope of the header is optional.
Any line of the commit message cannot be longer 100 characters! This allows the message to be easier to read on GitHub or any other Git tool;
Samples:
docs(changelog): update changelog to beta.5
fix(release): need to depend on latest rxjs and zone.js
Type
Must be one of the following:
build: Changes that affect the build system or external dependencies (e.g: npm)
build(ASM-123): update of the packages.json new versions of node
ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
ci(ASM-123): update of ci travis files in order to allow deploy to the new environments
docs: Documentation only changes
docs(ASM-123): adding a new documentation to the card-component
feat: A new feature
feat(ASM-123): working on the card-component feature
fix: A bug fix
fix(ASM-123): bugfixing of the start date on the card-component
perf: A code change that improves performance
perf(ASM-123): performance improvement on the get method.
refactor: A code change that neither fixes a bug nor adds a feature
refactor(ASM-123): refactoring the legacy post method to the new version of the framework.
style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
style(ASM-123): removing semi-colons not required
test: Adding missing tests or correcting existing tests
test(ASM-123): adding new test cases to the post method
Scope
The scope should be the ticket of the change you're working on for example: (ABC-123, CBA-432 and so on). That will give visibility on what that commit was worked on.
Thank you
By my experience, we've been using this approach and my current team and our it made our life a lot easier when seeking for a commit on the three. Give you a change and favourite this post. See you soon mate!
Top comments (0)