Git Health - Repository-Hygiene

Git Health betrachtet, wie ein Repository genutzt wird, nicht den Code darin: verwaiste Branches, ungeprüfte Merges, Force-Pushes auf geschützte Branches, übergroße Commits und ähnliche Hygiene-Signale.

Funktionsweise

• Läuft serverseitig gegen den Git-Provider mit dem verbundenen Zugangsdatensatz des Projekts - kein Collector, kein CI-Schritt. Jedes Projekt mit Zugangsdaten ist erfasst. Alle vier Git-Hoster sind abgedeckt - GitLab, GitHub, Bitbucket Cloud und Azure DevOps Repos; eine Regel, die ein Hoster nicht beantworten kann (etwa der Standard zum Löschen des Quellzweigs bei Bitbucket), wird übersprungen, nicht als fehlgeschlagen gewertet.
• Scans werden in eine Warteschlange gestellt und im Hintergrund verarbeitet; auslösbar am Projekt oder über die geplanten Scans.
• Jede Regel erzeugt einen Befund mit einem von vier Zuständen; der Projekt-Score ist eine gewichtete Summe - ein Force-Push wiegt schwerer als eine Namenskleinigkeit.

Merge-Gates und Push-Regeln

Über den Branch-Schutz hinaus liest Git Health, was ein Merge tatsächlich verlangt und was der Schutz noch durchlässt:

• Freigaben - ein Merge Request braucht mindestens eine Freigabe, mindestens zwei, und sein Autor kann ihn nicht selbst freigeben.
• Merge-Gates - Mergen setzt eine erfolgreiche Pipeline und gelöste Diskussionen voraus.
• Pushes auf den Standard-Branch - kein Force-Push und kein direkter Push ohne Merge Request. Ein geschützter Branch kann Maintainern oder namentlich eingetragenen Personen den direkten Push weiterhin erlauben: Das zählt zur Hälfte; können Entwickler pushen, zählt es gar nicht. Ein ungeschützter Branch wird einmal gemeldet, von der Branch-Schutz-Regel; die beiden Push-Regeln warten, bis der Branch geschützt ist.
• Tags - mindestens ein Tag ist geschützt, damit eine veröffentlichte Version nicht verschoben oder gelöscht werden kann. Verfolgt ein Projekt seine Releases über Tags, prüft die Release-Schutz-Regel diese Tags und diese Regel tritt zurück.

Gelesen wird das auf GitLab und GitHub; Bitbucket Cloud und Azure DevOps halten es in Branch-Richtlinien, die noch nicht gelesen werden, deshalb gelten die Regeln dort nicht. Tag-Schutz wird nur auf GitLab gelesen.

Achtung

Freigaben brauchen ein lizenziertes GitLab. Merge-Request-Freigaben sind eine Funktion von GitLab Premium / Ultimate. Auf einer GitLab-Free-Instanz werden die drei Freigabe-Regeln mit dem Hinweis Freigabe-Einstellungen erfordern ein lizenziertes GitLab übersprungen (nicht als fehlgeschlagen gewertet); die übrigen Regeln werden weiterhin beantwortet. GitHub braucht dafür keine Lizenz.

Die Pipeline-Regeln suchen neben Secret- und Abhängigkeits-Scans auch einen Schritt für statische Sicherheitsanalyse (SAST), Container-Image-Scans und eine erzeugte Software-Stückliste (CycloneDX oder SPDX). Eingebundene Dateien werden mitgelesen, auch GitLab-Vorlagen: Die Abhängigkeits- und Container-Scan-Vorlagen von GitLab erzeugen selbst eine CycloneDX-SBOM. Merge-Request- und Issue-Vorlagen werden als Dateien im Repository geprüft.

Hinweis

Git Health und Compliance teilen sich die Arbeit: Git Health liest die Provider-Einstellungen und die Pipeline (Branch-Schutz, Merge-Gates, CI-Schritte, eingecheckte Secret-Dateien), Compliance liest die eigenen Dokumente des Repositories (README, .gitignore, SECURITY.md, .editorconfig). Eine Lücke wird von einem der beiden gemeldet, nicht von beiden.

Ergebnisse lesen

• Projekt-Score und Note mit den Befunden dahinter; jeder erklärt, was beobachtet wurde und warum es zählt.
• Workspace-Ansicht - welche Projekte erfasst sind und welche nie gescannt wurden (nie gescannt wird als unbekannt gemeldet, nicht als gesund).
• Der Administrationsbereich zeigt dasselbe Bild installationsweit.

Hinweis

Regeln lassen sich pro Workspace anpassen; eine Regel, die nicht zum Workflow passt, wird abgeschaltet statt diskutiert.

Issue-Schlüssel, Sonar und Releases

• Branch-Regel verlangt einen Issue-Schlüssel (GIT_BRANCH_RULE_REQUIRES_ISSUE_KEY, GitLab) - die Push-Regel des Projekts (branch name regex) wird gelesen. Sie besteht, wenn die Regel einen Branch ohne Issue-Schlüssel (feature/add-login) ablehnt und einen mit Schlüssel (feature/PROJ-123-add-login oder kleingeschrieben feature/proj-123-...) annimmt. Bewertet wird, was die Regel mit Beispielnamen macht, nicht wie sie geschrieben ist.
• Sonar-Ergebnisse im Merge Request (CI_SONAR_MR_REPORT) - die Pipeline schreibt das SonarQube-Ergebnis in den Merge Request: ein Job, der es in die Beschreibung schreibt, oder Sonars eigene Merge-Request-Analyse (sonar.pullrequest.key). Eine Pipeline ohne SonarQube wird hier übersprungen; diese Lücke meldet die SonarQube-Regel.
• Kleingeschriebene Issue-Schlüssel zählen: bugfix/proj-123 nennt das Issue in der Branch-Namensregel so klar wie bugfix/PROJ-123.
• Release-Übernahmen - ein Merge Request, der einen release/-Branch in den Standard-Branch bringt, trägt alle Issues des Releases und zählt daher nicht für die Merge-Request-Titelregel, so wie Merge-Commits in der Commit-Regel nicht zählen.
• Schutz per Platzhalter - ein durch ein Muster (release/*) geschützter Branch gilt als geschützt, in der Release-Branch-Regel und überall sonst.
• Lock-Dateien werden bis drei Ordner tief gesucht (src/<layer>/<Project>/packages.lock.json), Code-Ordner zuerst; eine Suche, die der Scan nicht abschließen konnte, gilt als übersprungen, nie als fehlend.

Stillgelegte Regeln

Diese Regeln laufen nicht mehr. Befunde früherer Scans bleiben in der Historie; daneben steht, welche Regel dieselbe Frage jetzt beantwortet.

Regel	Ersetzt durch	Grund
REPO_README_PRESENT	Compliance DOC_README_EXISTS	Die Dokumente des Repositories prüft Compliance; dieselbe fehlende Datei wurde in beiden Modulen gemeldet.
REPO_GITIGNORE_PRESENT	Compliance REPO_GITIGNORE_EXISTS	Gleicher Grund.
REPO_SECURITY_MD_PRESENT	Compliance SEC_POLICY_EXISTS	Gleicher Grund.