Git

Naming

Repositories follow the naming convention of: <CLIENT_NAME>-<PROJECT_NAME>. Example klarna-signup.

Workflow

Use gitflow

Keep yourself within git-flow as far as possible. However, git is a tool in your arsenal, take advantage and create branches as you see fit. Talk to others in your team if needed. There are edge cases.

Feature branches

A feature is supposed to be small. Sometimes even just 2-3 commits. Try to limit your feature branch sizes. feature/startpage-with-menu is probably too big, feature/menu-item is probably better suited.

• Avoid merging broken code back into develop. Just dont.
• Name your feature branches using kebab-case convention.

Working with larger features and teammates

If your feature branch is large enough, you might want to store your branch over night. Feel free to push the feature branch to the repository. Once finished and merged with develop, delete the feature branch from the repository.

Sometimes a feature takes long before it's ready to merge into the develop. Please merge develop into your feature branch and correct any conflicts prior to feature completion. This will help keeping develop clean and prevent pushing broken code.

Two or more working on a single feature? Of course push your branch to the repository.

Commit messages

Follow the Erlang commit message guide for your commit messages. The gist of it is;

• Keep your summary short but explainatory
• Summaries are written imperative. Add is good. Added is bad.
• Explain what was supposed to have been committed. If it's hard to explain, your commit is probably too large.
• Description blocks are very useful for further info. These descriptions are most often omitted from your commit-tree overview but visible once you select a single commit.
• Breaking changes should be clearly stated

Deliveries and releases

Working with external people