KONNEKTING Development Rules

From KONNEKTING Wiki
Revision as of 09:39, 7 November 2020 by Konnekting (talk | contribs)
Jump to navigation Jump to search

How we work

We follow the GitLab Flow, you can read more about this in detail here: https://docs.gitlab.com/ee/topics/gitlab_flow.html


Gitlab Flow in a hurry

It all starts with an issue

Please make sure, you don't work on the code without having a backing issue in the issue tracker of the corresponding project on GitLab. The issue must describe the problem in detail with all required logs and details to understand the issue.

Create a branch for the issue

When you have an issue to work on, you first need to create a git branch based on the development branch for it. This has the advantage, that you can work very isolated on the issue, without affecting others work, or beeing afected from others code changes. And of course, through the GitLab pipeline, every branch is tested in every update for "still works" by actually compiling and testing the code

But you must follow a specific naming scheme when creating the branch. It is as follows:

{issue-number}-any-description

For example:

6-add-crc-checks

That way, GitLab is able to create a reference from the issue to the branch. So one can later follow the changes and find the corresponding branch for the issue.

Request to merge changes back

Once you're done with the changes on your "issue branch", you can start a merge-request to merge your changes back into "development" branch. The core development team will review the merge request.

If your changes do not meet the expected quality or if something is missing or misinterpreted, you will need to update your branch to meet the expectations. There is no need to create a new branch. Jst update the existing one.

Once the core development team has merged your branch, you can close/delete your branch, because it's not needed anymore. Through the link of the issue to the branch and the merge request, the changes are tracked.

How to contribute

to be done