Here's a place to share and document some tooling in use by Gitu, as well as tooling you may want to use.
There's CI that runs on every pull-request. This runs make test, which contains a few
extra commands over cargo test that you might find useful running locally.
Gitu makes heavy use of snapshot-testing with a library called Insta (https://insta.rs/). Most tests are written on a pretty high level. The philosophy is to keep the tests easy to reason about, and make refactoring painless.
Explain user-relevant changes in a feat:, fix:, style: or perf:.
Examples:
feat: ability to stage all files via "Unstaged changes" sectionfix: crash when opening Gitu on Windows
For minor, technical changes that are irrelevant to the user of Gitu, you can just use any other format:
refactor: changes some stufftest: added new test about xyzchanged something
The changelog is generated automatically using git-cliff (https://git-cliff.org/). There's no strict commit convention, but using certain formats will create a new entry. do:
You can see which commit formats contribute to a changelog in cliff.toml.
In order to create a release (by a maintainer). Run the bump.sh script. This will create a commit with appropriate changes to prepare for a release and tag it with a version. Push this commit (and tag) to master in order to kick off the release Github Actions.