Wie Ihre Repositorys geführt werden, an einem Ort bewertet.

Git Health prüft, wie jedes Repository geführt wird, nicht was darin steht: Ist der Standard-Branch geschützt, werden Merge Requests genehmigt, tragen Commits einen Issue-Key, laufen Sicherheitstools in der Pipeline, sind die nötigen Dateien da? 29 Regeln und ein gewichteter Score auf GitHub, GitLab, Bitbucket und Azure DevOps.

Kontakt aufnehmen Demo buchen

Bildschirme aus einer laufenden Installation

Sechs Gruppen, 29 Regeln

Jede Regel beantwortet eine Ja-Nein-Frage zur Führung des Repositorys und trägt einen Schweregrad und ein Gewicht.

5 Regeln

Branch-Schutz

Standard-Branch geschützt, keine direkten Pushes, keine Force-Pushes, Release-Branches und Tags geschützt.

6 Regeln

Merge-Request-Regeln

Genehmigung nötig, Mindestzahl an Genehmigungen, keine Selbstgenehmigung, Diskussionen gelöst und grüne Pipeline vor dem Merge, Quell-Branch danach gelöscht.

5 Regeln

Nachvollziehbarkeit

Commits und Merge-Request-Titel tragen einen Issue-Key, Branch-Namen folgen einem Muster, ein Issue-Tracker ist verbunden.

7 Regeln

Sicherheit in der CI

SAST, Secret-Erkennung, Abhängigkeits- und Container-Scans, eine SBOM und SonarQube mit MR-Berichten - in der Pipeline gefunden, eingebundene Vorlagen inklusive.

5 Regeln

Repository-Hygiene

CODEOWNERS, eine eingecheckte Lockfile, Merge-Request- und Issue-Vorlagen und keine eingecheckten Geheimnisdateien (Abgleich per Name; Inhalte werden nie gelesen). README, .gitignore und SECURITY.md prüft das Compliance-Modul.

1 Regeln

AppArch selbst

Ein Collector hat in den letzten 30 Tagen berichtet, die Scores überall sonst sind also aktuell.

Unbekannt ist nicht null

Eine Regel, die Plattform oder Token nicht beantworten können, gilt als übersprungen und zählt nicht zum Score. Eine Verbindung mit abgelaufenem Token zeigt „0 von 2 bewertbar“, nie „29 Fehler“. Ebenso bei einer Pipeline, die nicht ganz lesbar ist: Ein unlesbares Include heißt übersprungen, nicht fehlgeschlagen.

Keine Anmeldung, nichts von Hand zu starten

Jedes Projekt mit Git-Verbindung ist ab dem Moment dabei, in dem es angelegt wird.

01

Projekt anlegen

Der erste Scan wird eingeplant, sobald das Projekt angelegt ist.
02

Scans halten sich aktuell

Geplante Scans prüfen jedes Repository erneut; eine letzte Woche geänderte Einstellung taucht auf, ohne dass jemand fragt.
03

Beheben und Score beobachten

Jede verletzte Regel sagt, was sie gefunden hat; der Projekt-Score steht auf der Health-Karte neben den anderen Modul-Scores.

Was auf welcher Plattform geprüft werden kann

Nicht jede Plattform legt jede Einstellung über ihre API offen. Wo eine nicht antworten kann, wird die Regel übersprungen und zählt nicht zum Score; nie als Fehlschlag.

	GitLab	GitHub	Bitbucket	Azure DevOps
Standard- und Release-Branches geschützt
Merge-Regeln: Freigaben, keine Selbstfreigabe, grüne Pipeline, gelöste Threads			übersprungen	übersprungen
Kein Force-Push, kein direkter Push auf den Standardbranch			übersprungen	übersprungen
Quellbranch nach dem Merge gelöscht			übersprungen	übersprungen
Geschützte Tags, Issue-Schlüssel in Branch-Regeln		übersprungen	übersprungen	übersprungen
Issue-Schlüssel in Commits und MR-Titeln, Branch-Benennung
CODEOWNERS, Lockfile, Vorlagen, keine eingecheckten Geheimnisse			teilweise	teilweise
Sicherheitstools in CI: SAST, Secrets, Abhängigkeiten, Container, SBOM, SonarQube
Collector aktiv, Issue-Tracker verbunden

Regeln, die viele Elemente prüfen, geben Teilpunkte: Ein ungeschützter Branch von sieben kostet nicht so viel wie sieben.

Alle Merge Requests aller Anbieter in einer Liste

Git Health hält außerdem die Merge Requests des Workspaces an einem Ort, egal auf welcher Plattform sie liegen.

Nach Status, Projekt, Autor und Ziel-Branch filtern oder suchen
Ein Abzeichen verlinkt jeden geprüften MR mit seinem ArchPilot-Bericht
Architos Filter „länger als üblich“ zeigt, was hängt

Fragen zu Git Health

Welche Plattformen werden abgedeckt?

GitHub, GitLab (gitlab.com oder selbst gehostet), Bitbucket Cloud und Azure DevOps. Eine Regel, die eine Plattform nicht beantworten kann - Bitbucket und Azure DevOps haben etwa keine repositoryweite Einstellung zum Löschen des Quell-Branches -, wird übersprungen, nie als Fehler gewertet.

Liest es unseren Code?

Nein. Es liest Repository-Einstellungen, Branch- und Tag-Schutz, die letzten Commits und Merge Requests, die CI-Konfiguration und den Dateibaum. Geheimnisdateien werden über den Namen erkannt; ihr Inhalt wird nie gelesen.

Welche Rechte braucht das Token?

Lesezugriff deckt die meisten Regeln ab. Einige Einstellungen sieht nur ein Admin-Token - etwa GitHubs „Branch nach Merge löschen“; ohne ihn wird diese Regel übersprungen.

Verändert Git Health unsere anderen Scores?

Nein. Es hat einen eigenen Score, der auf der Health-Karte jedes Projekts neben den Scores von ArchScan, ArchSecurity und Compliance steht.