-
Notifications
You must be signed in to change notification settings - Fork 70
Commit Message Guidelines
This article lists guidelines for creating and formatting the commit messages in the kendo-themes repository.
We follow some rules as to how our Git commit messages can be best formatted in such a way that they are more readable and easy to follow when going through the project history. Moreover, we use the Git commit messages to generate the changelog.
The length of each commit message should not exceed 50 characters. This allows for a greater readability on GitHub and for using various Git tools.
Each commit message consists of a:
The following example demonstrates the regular pattern format of a commit message.
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
The header is mandatory to include in a commit message and follows a special pattern that contains:
The type header is mandatory and has to be any of the following options:
-
chore—A change that affects the build system or external dependencies. For example,
scopes: gulp, npm. - docs—A change in the documentation only.
- feat—A new feature.
- fix—A bug fix.
- perf—A change in the code for improving the performance.
- refactor—A change in the code that neither fixes a bug nor adds a feature.
- style—A change that does not affect the meaning of the code. For example, white-space, formatting, missing semi-colons, and other.
- test—An addition of missing tests or a correction of existing tests.
The following examples provide commit messages of the docs and fix types.
docs: add content on data back from server, fix links
fix: sync locked containers when height changes
The scope of the header is optional. It should be the name of the component which is affected, as perceived by someone who reads the changelog that was generated on the base of the commit messages.
The subject contains a succinct description of the change. When creating the subject:
- Use the Imperative Mood. For example, "change", and not "changed" or "changes".
- Don't capitalize the first letter.
- Don't put a period (
.) at the end. - Try to limit the subject to 50 characters. GitHub hides the rest of the message.
When creating the body:
- Use the Imperative Mood. For example, "change", and not "changed" or "changes".
- Include the motivation for the change and contrast this with the previous behavior.
When creating the footer:
- Include all the information about any Breaking Changes.
- Reference the GitHub issues that this commit Closes.
When implementing a Breaking Change commit message:
- Start with
BREAKING CHANGE:. - Follow the intro line with a space or two newlines. The rest of the commit message is then used to describe the change.