KONNEKTING Development Rules - Revision history

Konnekting: /* How to contribute changes as an 'external' */

2020-11-07T09:51:03Z

How to contribute changes as an 'external'

Konnekting at 09:50, 7 November 2020

2020-11-07T09:50:48Z

Konnekting: /* How to contribute changes as an external */

2020-11-07T09:47:25Z

How to contribute changes as an external

Konnekting at 09:47, 7 November 2020

2020-11-07T09:47:04Z

Konnekting at 09:44, 7 November 2020

2020-11-07T09:44:45Z

Konnekting at 09:44, 7 November 2020

2020-11-07T09:44:16Z

Konnekting at 09:39, 7 November 2020

2020-11-07T09:39:26Z

Konnekting at 09:35, 7 November 2020

2020-11-07T09:35:42Z

Konnekting: 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 == =..."

2020-11-07T08:46:35Z

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 == =..."

New page

== 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 coe 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 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:

<pre>
{issue-number}-any-description
</pre>

For example:

<pre>
6-add-crc-checks
</pre>

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.

← Older revision		Revision as of 09:51, 7 November 2020
Line 41:		Line 41:
	If you are not part of the core development team and thus have no right to push/commit to the project repository, you can yet contribute source code changes. All you need to do is to create a "fork" of the project. This means: Not just locally "git clone", but create a copy (=fork) of the repository on GitLab. In your own copy, you can still follow the rules described above. And once you're ready with your changes, you can start a request to merge your changes on your issue/feature branch into the main development branch of the KONNEKTING project. That's it.		If you are not part of the core development team and thus have no right to push/commit to the project repository, you can yet contribute source code changes. All you need to do is to create a "fork" of the project. This means: Not just locally "git clone", but create a copy (=fork) of the repository on GitLab. In your own copy, you can still follow the rules described above. And once you're ready with your changes, you can start a request to merge your changes on your issue/feature branch into the main development branch of the KONNEKTING project. That's it.

−	Please also keep in mind our [[KONNEKTING_Contributor_License_Agreement]] that ~~takes place~~ if you want to contribute.	+	Please also keep in mind our [[KONNEKTING_Contributor_License_Agreement]] that applies if you want to contribute.

← Older revision		Revision as of 09:50, 7 November 2020
Line 40:		Line 40:

	If you are not part of the core development team and thus have no right to push/commit to the project repository, you can yet contribute source code changes. All you need to do is to create a "fork" of the project. This means: Not just locally "git clone", but create a copy (=fork) of the repository on GitLab. In your own copy, you can still follow the rules described above. And once you're ready with your changes, you can start a request to merge your changes on your issue/feature branch into the main development branch of the KONNEKTING project. That's it.		If you are not part of the core development team and thus have no right to push/commit to the project repository, you can yet contribute source code changes. All you need to do is to create a "fork" of the project. This means: Not just locally "git clone", but create a copy (=fork) of the repository on GitLab. In your own copy, you can still follow the rules described above. And once you're ready with your changes, you can start a request to merge your changes on your issue/feature branch into the main development branch of the KONNEKTING project. That's it.
		+
		+	Please also keep in mind our [[KONNEKTING_Contributor_License_Agreement]] that takes place if you want to contribute.

@@ Line 37: / Line 37: @@
 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 changes as an external ==
+== How to contribute changes as an 'external' ==
 If you are not part of the core development team and thus have no right to push/commit to the project repository, you can yet contribute source code changes. All you need to do is to create a "fork" of the project. This means: Not just locally "git clone", but create a copy (=fork) of the repository on GitLab. In your own copy, you can still follow the rules described above. And once you're ready with your changes, you can start a request to merge your changes on your issue/feature branch into the main development branch of the KONNEKTING project. That's it.

@@ Line 37: / Line 37: @@
 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 changes as an 'external' ==
+== How to contribute changes as an external ==
 If you are not part of the core development team and thus have no right to push/commit to the project repository, you can yet contribute source code changes. All you need to do is to create a "fork" of the project. This means: Not just locally "git clone", but create a copy (=fork) of the repository on GitLab. In your own copy, you can still follow the rules described above. And once you're ready with your changes, you can start a request to merge your changes on your issue/feature branch into the main development branch of the KONNEKTING project. That's it.

@@ Line 37: / Line 37: @@
 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 ==
+== How to contribute changes as an 'external' ==
 If you are not part of the core development team and thus have no right to push/commit to the project repository, you can yet contribute source code changes. All you need to do is to create a "fork" of the project. This means: Not just locally "git clone", but create a copy (=fork) of the repository on GitLab. In your own copy, you can still follow the rules described above. And once you're ready with your changes, you can start a request to merge your changes on your issue/feature branch into the main development branch of the KONNEKTING project. That's it.

← Older revision		Revision as of 09:44, 7 November 2020
Line 39:		Line 39:
	== How to contribute ==		== How to contribute ==

−	to ~~be done~~	+	If you are not part of the core development team and thus have no right to push/commit to the project repository, you can yet contribute source code changes. All you need to do is to create a "fork" of the project. This means: Not just locally "git clone", but create a copy (=fork) of the repository on GitLab. In your own copy, you can still follow the rules described above. And once you're ready with your changes, you can start a request to merge your changes on your issue/feature branch into the main development branch of the KONNEKTING project. That's it.

← Older revision		Revision as of 09:39, 7 November 2020
Line 36:		Line 36:

	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.		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

@@ Line 8: / Line 8: @@
 === It all starts with an issue ===
-Please make sure, you don't work on the coe without having a backing issue in the issue tracker of the corresponding project on GitLab.
+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 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:
@@ 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.