Skip to content

Latest commit

 

History

History
62 lines (38 loc) · 2.22 KB

decision-record.md

File metadata and controls

62 lines (38 loc) · 2.22 KB
Raw

Decision Record

D-BC-001: conventinal commits for commit message formatting

Status

proposed by @peterbitfly

Context

At the moment commit messages are not formatted in a standard way. This makes it harder to work together, e.g. when resolving merge conflicts, using line blaming, to revert a change or understand the history of the project.

Especially to create release notes.

Decision

We are using Conventional Commits for commit messages.

Consequences

  1. Commit messsages MUST be formatted in conventional commits style.
  2. Every change that belongs together SHOULD be part of one commit.
  3. There MUST NOT be commits like implement review feedback or make linter happy.
  4. Teams (e.g. frontend, backend, mobile) SHOULD come up with guidelines regarding:
    1. types (teams SHOULD stick to the default set) and
    2. scopes
  5. One pull requesst MAY contain multiple commits.
  6. Every Pull Request (opened by a bitflyer) SHOULD have one commit that has a Footer with an issue number (like BEDS-XXX).
  7. Every Branch (created by a bitflyer) SHOULD contain the issue number as prefix (like BEDS-XXX/<name>)
  8. Before merging into staging all commits MUST be rebased (enforced by project settings).

References

  1. Conventional Commits
  2. Conventinal Commits Cheat Sheet
  3. Git Usage Example

👇 Template: copy from here 👇

D-BC-XXX: Short_title_of_solved_problem_and_solution

Status

proposed | rejected | accepted | deprecated | superseded by D-XXX

Context

What is the issue that we're seeing that is motivating this decision or change?

Decision

What is the change that we're proposing and/or doing?

Consequences

What becomes easier or more difficult to do because of this change?

References

  1. Documenting architecture decisions - Michael Nygard