Zum Inhalt springen

Planen Sie die Größe Ihres Git-Dienstes

Bevor Sie Ihren STACKIT Git Plan auswählen, bewerten Sie Ihre Teamgröße, die Repository-Nutzung und das erwartete Datenwachstum.

Analysieren Sie, wie Ihre Teams mit Git arbeiten:

  • Die Commit-Häufigkeit und die Repository-Größe beeinflussen den Speicherplatz und den Object Storage -Verbrauch.
  • Teams mit vielen binären Assets (z. B. Medien, Build-Artefakte) verbrauchen mehr Object Storage.
  • Größere Teams benötigen höhere Benutzerlimits und können vom größeren Plan profitieren, um Unterbrechungen zu vermeiden.
Plan  FestplattenspeicherObject StorageMax. Benutzer
Git10  1 GB10 GB10
Git10010 GB122 GB100

Wenn die Speicherkapazität überschritten wird, werden sowohl der Festplatten- als auch der Object Storage automatisch erhöht, um den Bedarf zu decken. Die Benutzerlimits und Basiskapazitäten bleiben jedoch durch den ausgewählten Plan definiert.

Ideal für:

  • Kleine Teams oder einzelne Entwickelnde
  • Leichtgewichtige Repositories (nur Quellcode, minimale binäre Assets)
  • Entwicklungs- oder Testumgebungen

Starten Sie mit Git10, wenn Ihr Team bis zu 10 Benutzer hat und Ihre Repositories unter wenigen Hundert Megabyte bleiben. Er ist eine wirtschaftliche Wahl für Projekte in der Frühphase oder Machbarkeitsstudien (Proof of Concepts).

Empfohlen für:

  • Mittlere bis große Entwicklungsteams (bis zu 100 Benutzer)
  • Projekte mit mehreren Repositories oder großen binären Artefakten
  • Continuous Integration/Continuous Deployment (CI/CD) -Workflows

Wählen Sie Git100, wenn Ihre Repositories kompilierte Binärdateien, Build-Ausgaben oder große Assets enthalten, die den Object Storage -Verbrauch erheblich erhöhen.

Der Speicher wird bei Bedarf automatisch skaliert, sodass Sie sich keine Sorgen machen müssen, dass Ihnen der Platz ausgeht. Wenn Ihr Team jedoch 10 Benutzer überschreitet oder Ihr Speicher kontinuierlich wächst, sollten Sie ein proaktives Upgrade von Git10 auf Git100 in Betracht ziehen.

  • Wachstum schätzen: Planen Sie die Erweiterung des Teams und des Repositories über 12 bis 24 Monate.
  • Nutzung überwachen: Überprüfen Sie regelmäßig die Auslastung des Repositories und des Object Storage.
  • Frühzeitig upgraden: Vermeiden Sie Unterbrechungen des Workflows durch ein Upgrade, bevor Sie Benutzer- oder Leistungslimits erreichen.