Contributing guide

October 20, 2025 · View on GitHub

We welcome contributions of all sizes, from documentation improvements to new features. This guide explains how to get started.

If you have

solved some known issue or
done changes to DiffKemp which you would like to share with the main repository,

read the following section:

Workflow

To contribute to DiffKemp, we use fork and pull request workflow.
When creating a pull request, you should check that all status checks are passing, if they are not, try to investigate the problems and fix them to make all status checks pass.
After creating the pull request, you can request review from a collaborator.
Wait for a review from a collaborator.
React to the reviewers' feedback, suggestions, questions – fixing problems and improving the pull request until the pull request is approved by the collaborator/s.
We use rebase and merge strategy for integrating the changes from the PR to the master branch.

In case there are merge conflicts conflicts between the master branch and the PR's branch, you will need to manually rebase the PR branch on the master branch and resolve the conflicts, to make it possible to merge your PR. You can use different tools for solving these conflicts.

A PR should be small, focused, and include a clear description (what, why, how).
A PR should have clean commit history:
- Each commit should be a logically separated change.
- There should not be "fix" or "small cleanup" commits – these should be either better described or merged (squashed) with some previous commit.
To clean up the commit history, you can use Git interactive rebase.
All CI checks should pass after each commit.

Each commit should had a commit message (not just the title) explaining what the change is and why it is useful or necessary.
Use 50/72 rule for commit messages.