3. Contributing Guide

FMDT code versioning is achieved thanks to Git. This section details how new contributions are integrated to the repository. There are two possible way to contribute depending on if your are a external contributor or if your are an inner contributor, see the next sections.

Important

The FMDT project exposes two mains protected branches: master and develop. The merge/pull requests are only accepted in the develop branch. In other words, all merge/pull requests targeting the master branch will be rejected.

Danger

Please read the coding conventions first in Section 2. Contributions that do not follow the coding and naming conventions will not be accepted!

3.1. Inner Contributions on GitLab

This is the inner workflow for people that have access to the private GitLab repository. In this repository, the master and develop branches are public because they are automatically mirrored on the public GitHub repository. By definitions, the other branches are private.

The way to contribute is to create a new branch from the develop to develop a new feature (lets call this a feature branch). When the feature branch is mature enough (and when it passes the CI pipeline). The developer should send a merge request (MR) from the feature branch into the develop branch. To send a MR in GitLab, you need to do it from the GitLab web interface. If you don’t know how to do that, you can refer to the official documentation here: https://docs.gitlab.com/ee/user/project/merge_requests/.

Once your MR is submitted, your code will be reviewed and accepted later if it matches the requirements.

3.2. External Contributions on GitHub

External contributions are also more than welcome. Everyone can access and clone the public FMDT repository from GitHub (https://github.com/alsoc/fmdt).

The way to contribute is to submit PR to the develop branch. This can be done from the GitHub web interface. If you don’t know how to do that, you can refer to the official documentation here: https://docs.github.com/en/pull-requests/.

Once your PR is submitted, your code will be reviewed and accepted later if it matches the requirements.

3.3. Workflow Git

Every contributions are firstly merged in the develop branch. When we consider that the current state of the develop branch is stable enough, a versioning tag (for instance v1.0.0) is added to a specific commit in the develop branch, then the develop branch is merge in the master branch.