Simplistic Commits 0.0.1

Like Conventional Commits, but more simplistic.

Summary

<type code>[<scope>:] <short description>

[optional body]

Examples:

D readme: D means docs

F gravicannon/constants: use correct gravity constant on Mars

N gravicannon: accept different mass classes
N launchpad: provide portals for different mass classes
F!gravicannon: use

Commits

"Modularize" your commits. Don’t make a giant, contains-everything commit.

First line

The first line is a summary of the commit. Should fit in 70 Unicode characters.

Type codes

Upper case letters.

N: feature implementation
F: fix
R: refactor
D: docs
P: performance improvement
T: test
B: build and CI/CD config
S: fix style, formatting, etc.
T: fix typo in code
U: fix typo in docs
V: bump version

For breaking changes, add ! after the type code, e.g. R!remove old control panels.

<type code> <short description>
<type code>!<short description> for breaking change
<type code> <scope>: <short description>
<type code>!<scope>: <short description> for breaking change

Don’t include multiple types in one commit. Break them down.

For the very first commit, don’t use 'init', 'initialize', or things like that. Describe what you actually did.

For documentation projects, like this one itself, use N, rather than D.

Scope(s)

To describe what module(s) the commit is changing, add an optional scope. Describe levels by /, like a file path.

If the commit involves multiple modules, write to the deepest common parent, e.g. alpha/one and alpha/two have the same parent alpha, then go with alpha. If multiple root modules are involved, don’t write a scope.

Short description

For N, or feature implementation, arrange it so it could fit in The code is now able to <description>, e.g. The code is now able to shoot farther under higher gravitation.

Be concise, use shorter words.

Should be in all lower case, except words that should be styled, e.g. API or GitHub.

No punctuation marks at the end.

Body

Can be omitted if the first line concisely describe in full what’s going on.

If the change consists of multiple smaller changes, list them by topics, or if they are on the same topic, by their modules. Use Markdown, AsciiDoc, or any markup your team agreed on.

Root modules are level two.

Add ! at the beginning for breaking changes.

Describe why the changes should be made, how the changes are made, what impacts they have, and why they are done this way, if necessary.