Richtlinien für das interne GitLab-System

1. Allgemeine Regeln

• Das GitLab-System dient der Verwaltung und Entwicklung des PommesBude.life Servers.
• Jeder Nutzer ist für seine eigenen Commits und Änderungen verantwortlich.
• Verhalte dich respektvoll und arbeite konstruktiv mit dem Team zusammen.
• Nutze sinnvolle Commit-Messages, um Änderungen nachvollziehbar zu machen.
• Jede Änderung muss über einen Merge Request (MR) erfolgen.
• Code-Reviews sind verpflichtend für alle MRs.

2. Repository-Struktur

Die Repositories werden von der Projektleitung festgelegt aufgebaut, um eine effiziente und wartbare Codebasis zu gewährleisten. Sie folgen einer klaren Architektur, die sich an bewährten Softwareentwicklungspraktiken orientiert. Jede Codebasis wird in dedizierte Module unterteilt, um Separation of Concerns (SoC) zu gewährleisten und eine saubere Projektstruktur beizubehalten.

Zusätzliche Informationen, einschließlich detaillierter Anweisungen zur Repositories-Nutzung, Branch-Policies und Deployment-Richtlinien, sind im Projekt-Wiki dokumentiert. Neue Repositories müssen von der Projektleitung genehmigt werden und einer standardisierten Namenskonvention folgen, um eine einheitliche Verwaltung zu ermöglichen.

3. Branching-Strategie

Wir verwenden ein eigenes Branching-Modell, das auf den erstellten Tickets basiert. Für jede neue Entwicklungsaufgabe wird ein Ticket im Issue-Tracker erstellt. Anschließend wird ein dedizierter Feature-Branch basierend auf dem Ticket generiert. Nach Abschluss der Implementierung wird der Branch als Merge Request (MR) eingereicht und einer Code-Review unterzogen.

Alle MRs müssen von einem Maintainer genehmigt werden. Die einzigen Maintainer mit Freigaberechten sind Jay und pentoxide. Nur sie dürfen Code in die Hauptbranches mergen.

4. Commit-Richtlinien

Commit-Richtlinien sind direkt mit den Ticket-Labels verknüpft, um eine konsistente und nachvollziehbare Entwicklung zu gewährleisten. Jedes Commit muss sich eindeutig auf ein zugehöriges Ticket beziehen und dessen Labeling-Struktur übernehmen. Dies stellt sicher, dass alle Änderungen im Kontext der Entwicklungsplanung stehen und eine klare Historie gewahrt bleibt.

Die Commit-Nachrichten müssen präzise formuliert und mit dem entsprechenden Ticket-Label versehen sein. Dadurch wird eine effiziente Changelog-Generierung und Nachverfolgbarkeit sichergestellt.

5. Merge Requests (MRs)

• Ein Merge Request darf erst erstellt werden, wenn die Arbeit an einem Branch vollständig abgeschlossen ist.
• Zwischen-Merges oder vorzeitige MRs sind ausdrücklich verboten.
• Jeder MR muss einem bestehenden Ticket zugeordnet sein.
• Mindestens eine andere Person muss den MR reviewen.
• Der Code muss vor dem Merge getestet werden.
• Nur die Maintainer Jay und pentoxide dürfen MRs final freigeben.

6. Code-Qualität & Testing

• Halte dich an den bestehenden Code-Stil und Konventionen.
• Führe lokale Tests durch, bevor du Code pushst.
• Automatische Tests müssen bestehen, bevor ein Merge erfolgt.
• Kommentiere komplexen oder schwer verständlichen Code ausreichend.

7. Sicherheit & Zugriff

• Zugriffsrechte werden individuell vergeben – halte deine SSH-Keys sicher.
• Teile keine sensiblen Daten (Passwörter, API-Keys) im Code.
• Nutze .gitignore, um lokale oder sicherheitskritische Dateien auszuschließen.
• Melde Sicherheitsprobleme sofort einem Admin.

8. Kommunikation & Dokumentation

• Diskutiere größere Änderungen im Issue-Tracker oder im Team-Chat.
• Dokumentiere neue Features oder größere Änderungen in den Docs.
• Halte Readme-Dateien aktuell, insbesondere für wichtige Repositories.

---

Diese Richtlinien helfen uns, effizient und organisiert am PommesBude.life Server zu arbeiten. Falls du Fragen hast, wende dich an die Projektleitung (Jay, pentoxide & HalberKeks) oder erstelle ein Issue im entsprechenden Repository.