Grenzwerte für Repositorys

Bestimmte Arten von Repositorys können ziemlich groß sein, wodurch ihre Verarbeitung auf GitHub sehr aufwendig ist. Daher werden Begrenzungen festgelegt, um sicherzustellen, dass Anforderungen in angemessener Zeit abgeschlossen werden. Die Überschreitung des empfohlenen Grenzwerts erhöht das Risiko einer verschlechterten Repositoryintegrität. Dabei kann es unter anderem zu langsamen Antwortzeiten bei grundlegenden Git-Vorgängen sowie zu Wartezeiten bei der Verwendung der Benutzeroberfläche kommen.

Die meisten der nachfolgend genannten Begrenzungen gelten sowohl für GitHub als auch für die API.

Repositorygröße

Es wird empfohlen, die folgenden Grenzwerte für die Struktur und Größe von Repositorys einzuhalten, um eine optimale Leistung und Verwaltbarkeit sicherzustellen.

• Größe auf dem Datenträger: 10 GB

  Die Angabe bezieht sich auf die Größe des .git-Ordners (der komprimierten Form des Repositorys). Große Repositorys können Abrufvorgänge verlangsamen und die Klondauer für Entwickler und CI erhöhen. Zum Verwalten der Repositorygröße hast du folgende Möglichkeiten:

  • Verwende Git Large File Storage (Git LFS) für Binärdateien.
  • Speichere programmgesteuert generierte Dateien außerhalb von Git, z. B. im Objektspeicher.

• Verzeichnisbreite (Anzahl der Einträge in einem einzelnen Verzeichnis): 3.000

  Verzeichnisse mit vielen häufig geänderten Dateien können die Wartungskosten für Repositorys deutlich erhöhen und die Leistung grundlegender Git-Vorgänge beeinträchtigen. Das Segmentieren von Dateien in eine flache Verzeichnisstruktur verringert die Größe dieser Strukturen und führt zu weniger neu erstellten Daten.

• Verzeichnistiefe: 50

  Tiefe Verzeichnisstrukturen können Verlaufsdurchläufe verlangsamen.

• Anzahl der Branches: 5.000

  Eine große Anzahl von Branches kann zu unnötig vielen Daten in Abrufvorgängen führen, was wiederum zu langsamen Übertragungszeiten oder in extremen Fällen zu einer gedrosselten Repositoryleistung führt.

Aktivität

Es wird empfohlen, die folgenden Betriebsgrenzwerte einzuhalten, um eine gedrosselte Leistung und Leistungsprobleme zu vermeiden.

• Pushgröße: Dieser Grenzwert wird bei 2 GB erzwungen.

• Größe eines einzelnen Objekts:

  Der empfohlene Höchstwert liegt bei 1 MB. Dieser Grenzwert wird bei 100 MB erzwungen. Zum Nachverfolgen großer Dateien in einem Git-Repository wird die Verwendung von Git LFS empfohlen. Weitere Informationen findest du unter Informationen zu Git Large File Storage.

• Git-Lesevorgänge (z. B. Abrufe, Klonen):

  Der empfohlene Höchstwert liegt bei 15 Vorgängen pro Sekunde und Repository. Eine große Anzahl von Lesevorgängen kann zu einer gedrosselten Leistung für ein Repository führen. Automatisierte Prozesse wie CI, Computerbenutzer oder Anwendungen von Drittanbietern können in einigen Fällen die Leistung eines Repositorys beeinträchtigen. Hier kannst du die Optimierung deiner CI-Klonstrategie und/oder die Verwendung eines Repositorycacheservers in Betracht ziehen. Beachte, dass flache Klone weniger Kosten und Auslastung auf dem Server verursachen als vollständige Klone und daher eine bessere Leistung aufweisen können.

• Pushrate: Der empfohlene Höchstwert liegt bei 6 Pushvorgängen pro Minute und Repository.

Textbeschränkungen

GitHub zeigt formatierte Vorschauen einiger Dateien an, z. B. Markdown- und Mermaid-Diagramme. GitHub versucht immer, diese Vorschauen zu rendern, wenn die Dateien klein sind (im Allgemeinen weniger als 2 MB), bei komplexeren Dateien kann es jedoch zu Zeitüberschreitungen kommen und sie werden entweder auf einfachen Text zurückgreifen oder gar nicht angezeigt. Diese Dateien sind immer in ihren Rohformaten verfügbar, die über HOSTNAME/user/repo/raw bereitgestellt werden; zum Beispiel, https://HOSTNAME/user/repo/raw/octocat/Spoon-Knife/master/index.html. Klicke auf die Schaltfläche Roh, um die unformatierte URL einer Datei zu erhalten.

Grenzwerte für Pull Requests

Es wird empfohlen, die folgenden Grenzwerte einzuhalten, um Verzögerungen und Leistungsprobleme in Repositorys mit einer hohen Pull Request-Aktivität zu vermeiden.

• Offene Pull Requests (für denselben Branch): 1.000

  Bei vielen offenen Pull Requests mit demselben Zielbranch kann es zu einer verlangsamten Überprüfung der Zusammenführbarkeit oder zu Timeouts kommen. Wenn du eine Mergewarteschlange verwendest, solltest du möglicherweise die Einstellung „Require this branch to be up to date before merging“ deaktivieren. Dadurch werden bei der Überprüfung der Zusammenführbarkeit nur die Pull Requests in der Warteschlange überprüft.

• Mergerate für Pull Requests: 1 zusammengeführter Pull Request pro Minute

  Bei jedem Mergevorgang wird die Zusammenführbarkeit für alle offenen Pull Requests überprüft, was zu Leistungsengpässen – insbesondere in ausgelasteten Repositorys – führen kann. Dadurch kann es auch zu einer Art Racebedingung bei der Zusammenführung kommen, die Auswirkungen auf die Produktivität von Entwicklern hat. Deaktiviere die Einstellung „Require this branch to be up to date before merging“, wenn du eine Mergewarteschlange verwendest, um die Auslastung zu verringern.

Diff-Beschränkungen

Da Diffs sehr groß werden können, gelten Diff-Beschränkungen für Commits, Pull Requests und Vergleichsansichten:

• In einem Pull Request darf kein Gesamtdiff 20.000 Zeilen, die geladen werden können, oder 1 MB rohe Diffdaten überschreiten.
• Kein einzelnes Diff darf 20.000 Zeilen, die geladen werden können, oder 500 KB rohe Diffdaten überschreiten. Vierhundert Zeilen und 20 KB werden für eine einzelne Datei automatisch geladen.
• Die Höchstzahl an Dateien in einem einzigen Diff liegt bei 300.
• Die Höchstzahl renderbarer Dateien (wie Bilder, PDF- und GeoJSON-Dateien) in einem einzigen Diff liegt bei 25.

Einige Teile einer eingeschränkten Diff werden möglicherweise angezeigt, aber alles, was über die Begrenzung hinausgeht, wird nicht angezeigt.

Commit-Listenbeschränkung

Die Seiten „Ansicht vergleichen“ und „Pull Requests“ zeigen eine Liste von Commits zwischen den Überarbeitungen base und head an. Diese Listen sind auf 250 Commits beschränkt. Wenn diese Grenze überschritten wird, gibt ein Hinweis an, dass weitere Commits vorhanden sind (aber sie werden nicht angezeigt).

Die Höchstzahl von Commits, die auf der Registerkarte „Commits“ angezeigt wird, beträgt 10.000. Verwenden Sie andere Tools, z. B. git rev-list --count mybranch zum Zählen und Aufzählen eines hohen Commit-Volumens bei Bedarf.

Grenzwerte für Rebases

Das Mergen eines Pull Requests mithilfe der Option „Rebase and merge“ ist auf 100 Commits beschränkt. Wenn du über einen Pull Request mit mehr als 100 Commits verfügst, musst du einen Mergecommit erstellen, squashen und mergen oder die Commits in mehrere Pull Requests aufteilen.

Organisations- und Kontogrenzwerte

Organisationen und Konten dürfen 100.000 Repositorys nicht überschreiten. Wenn ein Konto 50.000 Repositorys überschreitet, wird ein Banner angezeigt, das darauf hinweist, dass der Grenzwert bald erreicht ist. Darüber hinaus erhalten administrierende Personen E-Mail-Benachrichtigungen, und das Überwachungsprotokoll wird alle 5.000 weiteren Repositorys aktualisiert. Weitere Informationen findest du unter Informationen zu Repositorys.

Integrationen und GitHub Apps

Speichere beim Erstellen einer Integration in GitHub benutzergenerierte Daten in den eigenen GitHub-Konten der Benutzenden, anstatt sie in deinem Konto zu zentralisieren. Dadurch wird sichergestellt, dass Benutzende die volle Kontrolle über ihre Arbeit behalten und verhindert, dass Repositorygrenzwerte überschritten werden.