Branch-Schutz
Apothem-Branch-Schutz auf main: die aktuell geltende Schutzregel, ihre erforderlichen Statusprüfungen und die Prüfungen, deren Aufnahme aussteht.
Der main-Branch von Apothem ist durch eine klassische GitHub-Branch-Schutzregel geschützt. Das Repository hat keine Rulesets. Der Schutz setzt die in rules/production-ready-prs.md deklarierte Change-Set-Disziplin durch und speist die OpenSSF-Scorecard-Prüfungen Branch-Protection und Code-Review.
Diese Seite hält die aktuell geltenden Einstellungen exakt fest, wie sie zuletzt am 2026-10-07 aus der GitHub-API gelesen wurden. Eine Einstellung, die der Maintainer beabsichtigt, aber noch nicht angewendet hat, erscheint nur unter Ausstehende Maintainer-Änderungen.
Schutzeinstellungen
| Einstellung | API-Feld | Aktueller Wert | Wirkung |
|---|---|---|---|
| Pull Request vor dem Merge erforderlich | required_pull_request_reviews (vorhanden) | ✅ | Änderungen erreichen main über einen Pull Request. |
| Erforderliche genehmigende Reviews | required_approving_review_count | 0 | Ein Pull Request wird ohne genehmigende Review gemergt. Siehe Solo-Maintainer-Modell. |
| Veraltete Genehmigungen bei neuen Commits verwerfen | dismiss_stale_reviews | ✅ | Eine Genehmigung, die vor einem neuen Push erteilt wurde, zählt nicht mehr. |
| Review von Code Owners erforderlich | require_code_owner_reviews | ❌ | Dies zu aktivieren, bevor ein zweiter Maintainer hinzukommt, führt die Pull Requests eines Solo-Maintainers in eine Sackgasse. |
| Genehmigung des jüngsten überprüfbaren Pushes erforderlich | require_last_push_approval | ❌ | GitHub verlangt, dass diese Genehmigung von jemand anderem als der Person stammt, die gepusht hat, was ein Solo-Maintainer nicht leisten kann. |
| Bestehen von Statusprüfungen erforderlich | required_status_checks | ✅ | Die 12 Kontexte, die unter Erforderliche Statusprüfungen aufgeführt sind, müssen bestehen. |
| Branches müssen vor dem Merge aktuell sein | required_status_checks.strict | ❌ | Ein Pull Request kann gemergt werden, wenn seine erforderlichen Prüfungen gegen einen älteren Stand von main bestanden haben. Die Workflows, die bei einem Push auf main laufen, testen dann das gemergte Ergebnis. |
| Auflösung von Konversationen vor dem Merge erforderlich | required_conversation_resolution | ✅ | Offene Review-Threads blockieren den Merge. |
| Signierte Commits erforderlich | required_signatures | ❌ | Release-Commits werden lokal signiert. Die Durchsetzung wartet, bis die Onboarding-Dokumentation für Mitwirkende die Einrichtung der SSH- oder GPG-Signierung beschreibt. |
| Lineare Historie erforderlich | required_linear_history | ✅ | Hält die öffentliche Historie von main als eine einzige Linie. |
| Branch sperren | lock_branch | ❌ | main nimmt Merges an. |
| Umgehen der obigen Einstellungen nicht zulassen | enforce_admins | ❌ | Die obigen Einstellungen binden keinen Repository-Administrator. Ein Administrator kann ohne die erforderlichen Prüfungen mergen oder direkt auf main pushen. |
| Force-Pushes zulassen | allow_force_pushes | ❌ | Force-Pushes auf main sind für alle blockiert, Administratoren eingeschlossen. |
| Löschungen zulassen | allow_deletions | ❌ | Niemand kann main löschen, Administratoren eingeschlossen. |
Solo-Maintainer-Modell
Das Repository hat einen Maintainer. GitHub stellt fest: „Pull-Request-Autoren können ihre eigenen Pull Requests nicht genehmigen.“ Eine erforderliche Genehmigungsanzahl über 0 würde daher jeden Pull Request des Maintainers blockieren. Die aktuell geltende Regel verlangt einen Pull Request mit 0 Genehmigungen und lässt enforce_admins ausgeschaltet.
Für alle ohne Administratorberechtigung erfordert ein Merge weiterhin grüne erforderliche Statusprüfungen, aufgelöste Review-Konversationen und eine lineare Historie. Force-Pushes und das Löschen von main bleiben für jedes Konto blockiert.
Wenn ein zweiter Maintainer hinzukommt, sind die stärkeren Einstellungen mindestens eine erforderliche Genehmigung, die Genehmigung des jüngsten Pushes, die CODEOWNERS-Review und eingeschaltetes enforce_admins. Die Merge-Zeremonie für Solo-Maintainer gilt nur für einen Schutz, der eine Genehmigung verlangt und sie für Administratoren durchsetzt.
Erforderliche Statusprüfungen
Jeder dieser 12 Kontexte ist erforderlich, mit GitHub Actions (App-ID 15368) als Quelle:
quality / ubuntu-latest / py3.10
quality / ubuntu-latest / py3.11
quality / ubuntu-latest / py3.12
quality / ubuntu-latest / py3.13
quality / ubuntu-latest / py3.14
quality / windows-latest / py3.10
quality / windows-latest / py3.11
quality / windows-latest / py3.12
quality / windows-latest / py3.13
quality / windows-latest / py3.14
coverage
Require Signed-off-by| Kontext | Workflow und Job | Wie er bei jedem Pull Request meldet |
|---|---|---|
quality / <os> / py<ver> (10) | ci.yml, Job quality | ci.yml läuft, wenn ein Pull Request einen Code- oder Konfigurationspfad berührt. ci-docs-stub.yml meldet dieselben Kontexte bei einem Pull Request, der nur die Dokumentation ändert. |
coverage | ci.yml, Job coverage | Wie bei quality. |
Require Signed-off-by | dco.yml, Job dco | Sein Pull-Request-Trigger hat keinen paths-Filter, daher läuft er bei jedem Pull Request auf main. |
Die Prerelease-Matrixzelle quality / ubuntu-latest / py3.15 läuft in ci.yml mit continue-on-error und ist nicht erforderlich. Jeder andere Workflow, einschließlich CodeQL, Scorecard und pip-audit, kann einen Status melden, aber sein Ergebnis steuert den Merge nicht, es sei denn, sein Kontext wird in diese Liste aufgenommen.
Ausstehende Maintainer-Änderungen
Der Maintainer beabsichtigt, diese 25 Kontexte in die Liste der erforderlichen Prüfungen aufzunehmen. Der Header jedes Workflows deklariert den Job als erforderliche Prüfung, und sein Pull-Request-Trigger hat keinen paths-Filter, daher läuft er bei jedem Pull Request auf main. Bis ein Kontext aufgenommen ist, blockiert ein Fehlschlag darin den Merge nicht.
clean-install-gate.yml, 7 Kontexte:
installer-shell-compat / ubuntu-latest
installer-shell-compat / macos-latest
installer-shell-compat / windows-latest
clean-install-gate / ubuntu-latest
clean-install-gate / windows-latest
wheel-smoke / ubuntu-latest
wheel-smoke / windows-latestharness-matrix.yml, 17 Kontexte, ein matrix (<adapter>) pro Adapter in der Matrix des Jobs:
matrix (antigravity)
matrix (claude-code)
matrix (codebuddy)
matrix (codex)
matrix (cursor)
matrix (gemini-cli)
matrix (github-copilot)
matrix (glm)
matrix (hermes)
matrix (kimi-code)
matrix (kiro)
matrix (open-claw)
matrix (opencode)
matrix (qwen-code)
matrix (trae)
matrix (windsurf)
matrix (zed)installer-lint.yml, 1 Kontext:
installer-lintSobald die harness-matrix.yml-Kontexte erforderlich sind, fügt die Registrierung eines neuen Adapters einen matrix (<adapter>)-Kontext hinzu, und die Liste der erforderlichen Prüfungen erhält ihn in derselben Änderung. „Branches müssen vor dem Merge aktuell sein“ bleibt ausgeschaltet. Wenn eine ausstehende Änderung angewendet wird, verschieben Sie sie in derselben Änderung in die obigen Abschnitte zu den aktuell geltenden Einstellungen.
Audit-Kadenz
Diese Datei wird bei jedem Sicherheitsaudit und an jedem Release-Engineering-Kontrollpunkt überprüft. Eine Abweichung zwischen dieser Datei und der tatsächlichen Branch-Schutz-Konfiguration ist ein Befund mit hoher Schwere. Lesen Sie die aktuell geltende Konfiguration mit:
gh api repos/ahmed-g-gad/apothem/branches/main/protection
gh api repos/ahmed-g-gad/apothem/rulesetsReferenzen
- OpenSSF Scorecard — Branch-Protection-Prüfung
- GitHub — Informationen zu geschützten Branches
- GitHub — Eine Branch-Schutzregel verwalten
- GitHub — Einen Pull Request mit erforderlichen Reviews genehmigen
- Apothem CODEOWNERS — pfadbezogenes Review-Eigentum
- Apothem-CI-Workflows — die Workflows, aus denen jeder erforderliche Kontext stammt
rules/production-ready-prs.md§1 — Same-Change-Set-Disziplin, die dieser Schutz durchsetzt