# Adding something to the project
git add {FILE_NAME}# Checking if the file was added
git status# Commit the changes
git commit -m "message following the patterns below"
git push<type>(<optional scope>): <description> empty separator line <optional body> empty separator line <optional footer>
Revert "<reverted commit subject line>"
Follows default git revert message
- API relevant changes
featCommits, that adds or remove a new featurefixCommits, that fixes a bug
refactorCommits, that rewrite/restructure your code, however does not change any API behaviourperfCommits are specialrefactorcommits, that improve performance
styleCommits, that do not affect the meaning (white-space, formatting, missing semi-colons, etc)testCommits, that add missing tests or correcting existing testsdocsCommits, that affect documentation onlybuildCommits, that affect build components like build tool, ci pipeline, dependencies, project version, ...opsCommits, that affect operational components like infrastructure, deployment, backup, recovery, ...choreMiscellaneous commits e.g. modifying.gitignore
The scope provides additional contextual information.
- Is an optional part of the format
- Allowed Scopes depends on the specific project
- Don't use issue identifiers as scopes
Breaking changes should be indicated by an ! before the : in the subject line e.g. feat(api)!: remove status endpoint
- Is an optional part of the format
The description contains a concise description of the change.
- Is a mandatory part of the format
- Use the imperative, present tense: "change" not "changed" nor "changes"
- Think of
This commit will...orThis commit should...
- Think of
- Don't capitalize the first letter
- No dot (
.) at the end
The body should include the motivation for the change and contrast this with previous behavior.
- Is an optional part of the format
- Use the imperative, present tense: "change" not "changed" nor "changes"
- This is the place to mention issue identifiers and their relations
The footer should contain any information about Breaking Changes and is also the place to reference Issues that this commit refers to.
- Is an optional part of the format
- optionally reference an issue by its id.
- Breaking Changes should start with the word
BREAKING CHANGES:followed by space or two newlines. The rest of the commit message is then used for this.
- https://www.conventionalcommits.org/
- https://github.com/angular/angular/blob/master/CONTRIBUTING.md
- http://karma-runner.github.io/1.0/dev/git-commit-msg.html
- https://github.com/github/platform-samples/tree/master/pre-receive-hooks
- https://github.community/t5/GitHub-Enterprise-Best-Practices/Using-pre-receive-hooks-in-GitHub-Enterprise/ba-p/13863