git is employed as a version-control system.
Please follow these rules for
git and GitLab:
- Start from one of issues or create a new one to formulate the problem. Skip this step for a minor contribution.
- Minimize the scope of a Merge Request (MR). Split a MR if possible.
- Keep your MR up-to-date by rebasing your branch on the target branch (usually
- Follow Conventional Commits Specification for commit messages.
- Name individual branches as
- Comment merge requests instead of individual commits in GitLab.
For maintainers only:
- Merge into the
trunkbranch only after the approval of at least one maintainer.
- Preserve a semi-linear history of commits.
- Prefer squashing in case of messy commits.
- Use "Merge with Merge Commit" as a default option via GitLab interface. Note that there is no confirmation button in GitLab. Double-check the history of commits and description of the merge commit, which usually contains list of improvements/fixes as well as references to the issues addressed.
- Use fast-forward merges for small features or bug fixes via command line tools.
trunkbranch before pushing it to the GitLab repository.