Commit 92f4b5a7 authored by Jakub Klinkovský's avatar Jakub Klinkovský

Add contribution guide

parent eb50ba22
## How to configure git
It is important to [configure your git username and email address](,
since every git commit will use this information to identify you as the author:
git config --global "John Doe"
git config --global ""
In the TNL project, this username should be your real name (given name and
family name) and the email address should be the email address used in the
Gitlab profile. You should use the same configuration on all computers where
you make commits. If you have made some commits with a different email address
in the past, you can also add secondary email addresses to the Gitlab profile.
## How to write good commit messages
Begin with a short summary line a.k.a. message subject:
- Use up to 50 characters; this is the git official preference.
- Finish without a sentence-ending period.
Continue with a longer description a.k.a. message body:
- Add a blank line after the summary line, then write as much as you want.
- Use up to 72 characters per line for typical text for word wrap.
- Use as many characters as needed for atypical text, such as URLs, terminal
output, formatted messages, etc.
- Include any kind of notes, links, examples, etc. as you want.
See [5 Useful Tips For A Better Commit Message]( and
[How to Write a Git Commit Message](
for examples and reasoning.
## How to split commits
Extensive changes should be split into multiple commits so that only related
changes are made in each commit. All changes made in a commit should be
described in its commit message. If describing all changes would not result in
a good commit message, you should probably make multiple separate commits.
Multiple small commits are better than one big commit, because later they can be
easily [squashed](
together, whereas splitting a big commit into logical parts is significantly
more difficult.
> __Tip:__ Use `git add -p` to stage only part of your working tree for the next
> commit. See [git add -p: The most powerful git feature you're not using yet](
## Rebase-based workflow
The development of new features should follow the rebase-based workflow:
- Create a new _feature_ branch based on the main branch (`develop`).
- Make commits with your work in the feature branch.
- When there are other new commits in the `develop` branch, you should do a
[rebase]( to rewind your
commits on top of the current develop branch.
- If there are conflicts, you will need to resolve them manually. Hence, it
is a good practice to rebase as often as possible (generally as soon as
the changes appear in the `develop` branch) and to split commits into
logical parts.
- When your work is ready for review, you can open a [merge request](
- If the branch is not ready for merge yet, prepend `[WIP]` to the merge
request title to indicate _work in progress_ and to prevent a premature
- This is also a good time to squash small commits (e.g. typos, forgotten
changes or trivial corrections) with relevant bigger commits to make the
review easier.
- When reviewed, the feature branch can be merged into the develop branch.
The main advantages of this workflow are linear history, clear commits and
reduction of merge conflicts. See [A rebase-based workflow]( and
[Why is rebase-then-merge better than just merge](
([complement]( for reference.
\ No newline at end of file
Markdown is supported
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment