The following linters are configured to find errors and check for code style compliance:
- TSLint in
tslint.jsonfor TypeScript - StyleLint in
.stylelintrcfor SCSS
Code style compliance is enfored when merging back to master.
Commit messages are formatted according to AngularJS commit message guidelines. This enables automatic generation of the changelog from commit messages.
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.
Must be one of the following:
- feat: A new feature
- fix: A bug fix
- docs: Documentation only changes
- style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
- refactor: A code change that neither fixes a bug nor adds a feature
- perf: A code change that improves performance
- test: Adding missing tests
- chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
The scope is the lowercase module name. It can be omitted for changes with global impact.
The subject contains succinct description of the change:
- use the imperative, present tense: "change" not "changed" nor "changes"
- don't capitalize first letter
- no dot (.) at the end
Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.
The footer is the place to reference issues that this commit closes.
The branching strategy adheres to the git flow model:
- master is the eternal production branch
- develop ist the eternal development branch
- Release branches are branched off develop and contain work aimed for the release. Release branches are named by version, e.g.
release/1.2.0. Once the release is ready, the top of the branch is tagged with the release version and into master. - Hotfix branches are branched off master at the specific version's release tag. Hotfix branches are named by version, e.g.
hotfix/1.2.1. Once the hotfix is ready, the procedure is the same as for release branches. - Feature branches are branched off develop and contain work aimed to complete a specific task (feature, fix, etc). Feature branches are named by issue nr and description, e.g.
feature/project-12-home-screen
Feature branches are explicitly merged back using pull requests for code review. A local history clean-up rebase before sharing a feature branch for review is absolutely encouraged.
This helps keeping information about the historical existence of a feature branch and groups together all commits part of the feature.
Release branches are tagged with the version number before merging. The tag is formatted according to the npm version command: v[VERSION>
Version numbers are incremented according to Semantic Versioning.
Given a version number [MAJOR].[MINOR].[PATCH], increment the:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards-compatible manner, and
- PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-releases are available as extensions to the [MAJOR].[MINOR].[PATCH] format:
- [MAJOR].[MINIOR].[PATCH]-beta.[NUMBER]
- [MAJOR].[MINIOR].[PATCH]-rc.[NUMBER]