# Contribution conventions ## Branch conventions - `/[/, ...]` ### `` This should be one of: * `feature` For work on a feature, look at `feat` commit type description for further info. * `fix` For fixing a but in a feature, look at `fix` commit type description * `refactor` Look at `refactor` commit type description * `hotfix` Temporary quick fixes of critical errors to master * `release` Pre-release finalization changes Examples: - `feature/note_preview` - working on feature `note_preview` in `src/feature/note_preview` directory - `feature/note_graph/note_graph_ui` - working of submodule `note_graph_ui` of module `note_graph` in `src/feature/note_graph` directory - `fix/configuration` - fixing how configuration works (it was doing unwraps/expects, rewrite it to returning `Result`s, which is breaking API change and technically crash fix so not refactor, and not a feature because nothing new was added) - ~`feature/graph-trait`~ - This is now the branch that added `src/lib/graph.rs` was named. At first i was thinking that it is hard to fit such a fundamental thing to the feature model, but it's not that fundamental. It's primarily a part of `note_graph` feature, and so **ones like this should be named feature-first, not library-first**. Most of the time if you adding something you add it for some feature. If most of your work in this branch is a library, for example a force-directed placement implementation or a environment variable substitution parser, it is still done first for some feature, specifically `note_graph` and accordingly `configuration` in that case. ### `` This should be one of, in priority order: - `feature/` module name that you're currently working on - meaningful short description or a naming for your scope, separated with dashes (`-`), one or a couple of words ### `` This should be one of, in priority order: - `feature/` submodule, like `note_graph/note_graph_ui` - meaningful short description or a naming for your scope, separated with dashes (`-`), one or a couple of words ## Commit conventions ### Pull requests For pull request merges, use the default message, which is `Merge pull request #N from ` Follow ### Merges **Don't use merges** for your own local things. **Use rebases**. ``` Merge branch '' ``` *Follows default git merge message* TODO: maybe rebase all the history to be the above with some changes to it (it has to have the pull request number in it) ### Default [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) The format is: ``` [()][!]: [] [] ``` **Including the empty lines** ### `!` * This means that this commit introduces a breaking change. ### `` * `feat` Commits, that adds a new feature or changes how the old feature works. Should only be user-presented features, changes to logic that does not affect what user of the app sees is `refactor`. * `fix` Commits, that fix a bug * `refactor` Commits, that rewrite/restructure your code, however does not change any behaviour * `perf` Commits are special `refactor` commits, that improve performance * `style` Commits, that do not affect the meaning (white-space, formatting, missing semi-colons, etc) * `test` Commits, that add missing tests or correcting existing tests * `docs` Commits, that affect documentation only * `build` Commits, that affect build components like build tool, dependencies, project version, ... * `ci` Commits, that affect the CI pipeline * `chore` Miscellaneous commits e.g. modifying `.gitignore` * `revert` Commits that revert other commits ### `` This should be one of, in priority order: - `feature/` module name that you're currently working on - meaningful short description or a naming for your scope, separated with dashes (`-`), one or a couple of words ### `` * Use the imperative, present tense: "change" not "changed", "add" not "added" * Don't capitalize the first letter * No dot (.) at the end ### `` * Use the imperative, present tense: "change" not "changed", "add" not "added" * This is the place to mention issue identifiers and their relations ### `` List of format: ``` : ``` * `BREAKING CHANGE: ` Same as the `!`, but with description. Can't be included without the `!`. * Mention closed issues - Example: `Closes: #1` * Stuff like skip CI for tools like Github Actions