Git
Gitflow
In our project we will use Gitflow workflow therefore, it is advisable to familiarize yourself with a basic understanding of how it works and why it is necessary.
Branch naming
Naming conventions for branch prefix
| prefix | Meaning |
|---|---|
| hotfix | for quickly fixing critical issues, usually with a temporary solution (only for prod) |
| bugfix | for fixing a bug |
| feature | for adding, removing or modifying a feature |
| test | for experimenting something which is not an issue |
| wip | for a work in progress |
Commit messages
Naming conventions for commit messages
The commit message should be structured as follows:
Schema
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
<type>: <description>
| Type | Meaning |
|---|---|
| feat | Commits, that adds or remove a new feature |
| fix | Commits, that fixes a bug |
| refactor | Commits, that rewrite/restructure your code, however does not change any API behaviour |
| style | Commits, that do not affect the meaning (white-space, formatting, missing semi-colons, etc) |
| test | Commits, that add missing tests or correcting existing tests |
| docs | Commits, that affect documentation only |
| build | Commits, that affect build components like build tool, ci pipeline, dependencies, project version, ... |
| ops | Commits, that affect operational components like infrastructure, deployment, backup, recovery, ... |
| chore | Miscellaneous commits e.g. modifying .gitignore |
Scope
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
In scope, I suggest using layer level. For example if you are using WSD layers and you fix bug with api endpoint you need use web word in scope
Description
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... or This commit should...
- Don't capitalize the first letter
- No dot (.) at the end
Body
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
Footer
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.
Examples
feat(web): remove ticket list endpoint
refers to JIRA-1337
BREAKING CHANGES: ticket enpoints no longer supports list all entites.
fix(api): fix wrong calculation of request body checksum