Skip to content

Contributing: Commit message advice #24

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Nov 10, 2025
Merged

Contributing: Commit message advice #24

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
2c51aa9
Contributing: Commit message advice
xrvdg Sep 4, 2025
27e13d1
fixup! Contributing: Commit message advice
xrvdg Sep 4, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 13 additions & 2 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,12 +1,23 @@
# Contributor's guide

## Commit signing
## Commits
### Commit signing

Enable [commit signing](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits)

```sh
git config commit.gpgsign true
```

### Commit messages

Strive to write informative commit messages: a single line summary of the change and maybe a small exposition in the body of the message.
If you do write an exposition, include parts of it in the PR description and in the source code as well. This gives multiple avenues to find the motivation for the change.

Avoid writing commit messages like "wip", "fix", or drawn-out commit messages that actually say nothing. Use fixup commits instead, as these can be automatically squashed, thereby keeping the log clean.
To make a fixup commit: `git commit --fixup SHA`, where SHA points to the commit hash where, looking back, you would have liked to have made this change in the first place.
When you publish the branch for review, do `git rebase --autosquash` beforehand and the history will be clean. This way you'll have chronological checkpoints while developing. Upon publishing, you'll have a clean commit history that tells a logically constructive story without odd backreferences to earlier points.
Fixup commits are also useful during reviews, as they maintain the chronological points of the discussion and will be squashed out when merging.

## Prerequisites

Expand Down Expand Up @@ -106,4 +117,4 @@ But these 3 should be enough for the average application to identify bottlenecks

For async-rust we also recommend: [Tracing](https://crates.io/crates/tracing), [Tokio-Console](https://crates.io/crates/tokio-console), and [Oha](https://crates.io/crates/oha).
For Rayon-based parallel Rust code, we recommend Samply.
It provides good profiling despite missing some multithreading details.
It provides good profiling despite missing some multithreading details.