Difference between revisions of "KONNEKTING Development Rules"
Konnekting (talk | contribs) (Created page with "== 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 == =...") |
Konnekting (talk | contribs) |
||
| Line 8: | Line 8: | ||
=== It all starts with an issue === | === It all starts with an issue === | ||
| − | Please make sure, you don't work on the | + | 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. | The issue must describe the problem in detail with all required logs and details to understand the issue. | ||
=== Create a branch for the issue === | === Create a branch for the issue === | ||
| − | When you have an issue to work on, you first need to create a git 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 | + | 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: | But you must follow a specific naming scheme when creating the branch. It is as follows: | ||
| Line 28: | Line 28: | ||
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. | 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. | ||
Revision as of 09:35, 7 November 2020
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.