... | ... | @@ -4,7 +4,7 @@ This section defines our git-workflow for developers. Contributors should use th |
|
|
Merge Requests which aren't following our Merge-Contract (below) will be closed.
|
|
|
|
|
|
## The workflow
|
|
|
* Direct pushes to staging and master aren't allowed. There must be a new branch with a merge request for every topic (fixup (for a issue),feature, label-/text-changes, codestyles, refactoring, etc...). Don't mix topics like feature-implementation and refactoring.
|
|
|
* Direct pushes to staging and master aren't allowed. There must be a new branch with a merge request for every topic (fixup (for a issue), feature, label-/text-changes, codestyles, refactoring, etc...). Don't mix topics like feature-implementation and refactoring.
|
|
|
* On finishing coding, a Merge-Request to the staging-branch should be created. Merge Requests to Master will always be denied.
|
|
|
* A Master will review and test the MR. Better you test before (at least a smoke test, it's recommended to do some additional testing).
|
|
|
* Keep your MR up-to-date: There might be some other MR's which are handled before yours. You should rebase your branch just-in-time, MR's with merge conflicts will be closed, if they last longer than some days.
|
... | ... | @@ -12,4 +12,6 @@ Merge Requests which aren't following our Merge-Contract (below) will be closed. |
|
|
## Contract for Merge Requests
|
|
|
* Appreciate the code-styles (jshint and jscs). They are checked by two build-processes, MR's with failing builds will be closed.
|
|
|
* Keep it short and simple: One branch and MR for one bug / refactoring / feature etc. While dealing with big features, you should split your implementation into many MR's. Too much changes are hard to review and can easily occure many errors because the more files you are touching, the more side-effects you get.
|
|
|
* Use the documentation: Explain what you did. If the reviewer doesn't understand your intention, he won't be able to review. If you introduce something new or you want to spread a word about infrastructure- or usage- changes, mention it in our [Wiki](https://git.thm.de/arsnova/arsnova.click/wikis/home). |
|
|
\ No newline at end of file |
|
|
* Use the documentation: Explain what you did. If the reviewer doesn't understand your intention, he won't be able to review. If you introduce something new or you want to spread a word about infrastructure- or usage- changes, mention it in our [Wiki](https://git.thm.de/arsnova/arsnova.click/wikis/home).
|
|
|
* You can create MR's before you're done. Those should always get the label WIP (work in progress) and some checkboxes in the describtion to explain which tasks are done or still open. Resultant is that others can test your feature and participate the discussion while it's still in work.
|
|
|
* If there is any kind of bug found while testing a MR, it should be written in the description with a unchecked box. If it's not existing, create a new header for Bugs/Issues. |
|
|
\ No newline at end of file |