3.3 KiB
Repository Regulations
Commit Messages
Adopted from conventional commits and Doom Emacs' variant
TYPE[!][(scope)]: SUBJECT
[BODY]
[FOOTER]
Types
bump
For updating inputs/packages, and any changes required to maintain working order post-update. Replace dump with revert then downgrading flake inputs.
bump: [flake inputs|INPUT]
chore
A regular and necessary commit to update regularly-changed files, such as those including timestamps or state information.
dev
Work on project infrastructure and development tools: build scripts, repository config files (.github/*, .direnv, .gitignore, etc.)
docs
Changes to documentation, docstrings, or help output for bud.
feat
For changes that introduce a new feature, a major UI/UX change, etc.
Changes that are minor should use the tweak type.
fix
A fix for a bug or behavior. Also used for updating code missed by the last dump.
merge
A merge commit, merging a pull request or branch.
- Never specify a scope
- The bang is meaningless
- The
SUMMARYshould only contain one or more pull request references/branch names
module
Reflects changes to the module list, such as adding, removing, renaming, or deprecating modules
- Not used for changes within modules
- Scope does after the colon
- If it is a user module, add
(user)to the type.
module: add desktop/gaming
module: move services/xserver to desktop/display
module: remove services/foldingathome
module(user): add programs/blugon
nit
Small nitpick changes with no effect on the code, such as whitespace, formatting, or comments.
refactor
Changes to code that does not add a feature or fix a bug. Includes removing redundant code, simplifying code, renaming variables, or swapping a package for a near-enough drop-in replacement.
revert
For reverting changes. SUBJECT should be the full subject of the reverted commit. (Add Revert HASH in FOOTER)
Rebase out commits where possible..
test
Changes to unit tests, but not testing infrastructure (use dev for that)
tweak
For minor UI/UX improvements/changes, or tweaks to variables/defaults with subtle or no user-facing changes.
Breaking changes
- Append a
!(aka bang) to theTYPEto indicate a breaking change - Prepend
BREAKING CHANGE:toBODY, followed by an explanation of what is broken and how to get around it,
Scope
The SCOPE should be one of the following:
- Module, without directory/category (
nit(gaming),tweak(xserver)) - Directory without the module, implying all modules within (
feat(desktop),fix(software)) - Arbitrary scope prefixed with
&(fix(&lutris),dev(&doom)) - A host, prefixed with
@(fix(@Infini-FRAMEWORK)) - A user, prefixed with
$(feat($infinidoge)) bud, for changes to thebudcommand- One or more of the above, separated with a comma. This is discouraged.
The scope may be omitted if:
- Using the
bump:,revert:,module:, ormerge:types. (Scope belongs inSUBJECT) - Is a change to global defaults, larger design decisions, etc.