decide ground rule

[starkensin]

• [x] branch strategy
• [x] commit message
• [x] issue labels
• [x] PR merge

[starkensin]

branch strategy

Adopt Trunk-based development with short-lived feature branch. It is modified by adding feature branch compared to original Trunk-based development.

reason: don't want to increase the complexity of branching strategy in small team.

In this strategy,

• main
• feature
  • format: feature/issue{issuenumber}-{description}
  • e.g.: feature/issue1-ground-rule
• release
  • format: release/v{majornumber}.{minornumber}.{patchnumber}-{semantics}
  • e.g.: release/v0.0.1-patch

branches are using.

about short-lived feature branch

• https://trunkbaseddevelopment.com/short-lived-feature-branches/

about Trunk-based development

https://www.atlassian.com/continuous-delivery/continuous-integration/trunk-based-development https://cloud.google.com/architecture/devops/devops-tech-trunk-based-development

[starkensin]

issue labels

add labels from time to time

[starkensin]

commit message

feat: A new feature
fix: A bug fix
docs: Changes to documentation
style: Formatting, missing semi colons, etc; no code change
refactor: Refactoring production code
test: Adding tests, refactoring test; no production code change
chore: Updating build tasks, package manager configs, etc; no production code change

commit message format: feat: what I make(#issue-number) or issue title(#issue-number)

https://udacity.github.io/git-styleguide/

[starkensin]

PR merge

the basic PR merge principle: at least one peer approval is needed. however, after 5 days from request, the PR could be merge without approval.