Die Wartungsarbeiten wurden erfolgreich abgeschlossen. Regelmäßige Updates unterstützen die Sicherheit von THM GitLab. Vielen Dank für Ihre Geduld!
Bei Problemen mit eigenen Runnern, siehe hier.
This section defines our git-workflow for developers. Contributors should use the [Contribution Guide](https://git.thm.de/arsnova/arsnova.click/blob/staging/CONTRIBUTING.md), because they haven't the permissions to create new branches. Thus they need to fork the project.
Merge Requests which aren't following our Merge-Contract (below) will be closed.
## Git-Workflow
* Direct pushes to staging and master aren't allowed. There must be a new branch with a merge request for every change (bugfixes, typos, label-/text-changes, codestyles, refactoring, etc...)
* 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 hours.
## 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).