Auf dieser Seite

Repository eingrenzen und Git-Werkzeuge konfigurieren

Große Repositorys, große Dateien und unterschiedliche Signaturidentitäten benötigen eigene Einstellungen. Öffnen Sie die passende Aktion für das aktive Repository, prüfen Sie die Vorschau und wenden Sie die für Ihre Aufgabe benötigte Änderung an.

Ein Monorepo mit Sparse Checkout eingrenzen

  1. Öffnen Sie Sparse Checkout und wählen Sie die benötigten Verzeichnisse. Das Filtern der Liste erhält Ihre Auswahl; die Auswahl eines übergeordneten Ordners macht die Auswahl seiner Unterordner überflüssig.
  2. Prüfen Sie die Anzahl sichtbarer Dateien. Der Cone-Modus erhält die gewählten Verzeichnisse, Dateien im Stammverzeichnis und Dateien direkt in den übergeordneten Verzeichnissen.
  3. Wählen Sie Sparse Index nur, wenn Ihre anderen Git-Werkzeuge es unterstützen. Es kann den Index verkleinern, garantiert aber weder schnellere Builds noch installiert es Projektabhängigkeiten.
  4. Wenden Sie die geprüfte Auswahl an. Ausstehende Änderungen, ignorierte Dateien oder eine andere Git-Operation können dies verhindern. Klären Sie den gemeldeten Zustand und erstellen Sie bei geändertem Repository eine neue Vorschau.
  5. Stellen Sie den vollständigen Arbeitsbaum wieder her, wenn Sie erneut alle erfassten Dateien benötigen.

Dies ändert, welche erfassten Dateien im Arbeitsbaum vorhanden sind, nicht den vollständigen Verlauf. Es führt keinen Partial Clone aus. Bestehende Non-Cone-Konfigurationen können deaktiviert, aber nicht mit der Auswahl bearbeitet werden. Die aktuellen Grenzen sind 250.000 Dateien, 20.000 Verzeichnisse und 1.000 ausgewählte Verzeichnisse; eine Überschreitung wird gemeldet, ohne die Auswahl unbemerkt zu kürzen.

Große Dateien mit Git LFS verwalten

Öffnen Sie die Repository-Erweiterungen, um Git LFS, seine Dateien, verfügbare Objekte und Regeln in der .gitattributes des Stammverzeichnisses zu prüfen. Die Aktionen setzen installiertes Git LFS ab Version 3.8.1 voraus.

  1. Installieren Sie bei Bedarf die LFS-Konfiguration für dieses Repository. Dies konfiguriert das Repository und installiert nicht das Git-LFS-Programm. Gemeinsam genutzte oder unsichere Hook-Pfade können die Aktion verhindern; bestehende Hooks werden nicht erzwungen ersetzt.
  2. Fügen Sie ein Muster zur Nachverfolgung hinzu oder entfernen Sie es und bestätigen Sie die Änderung. Prüfen Sie die resultierende .gitattributes und nehmen Sie sie gegebenenfalls in einen Commit auf.
  3. Wählen Sie ein Remote, um LFS-Objekte für HEAD abzurufen. Materialisieren Sie verfügbare Objekte anschließend bei Bedarf in den Arbeitsdateien.

Das Panel zeigt bis zu 2.000 Dateien und kennzeichnet eine teilweise Abdeckung. Es bearbeitet nicht sämtliche untergeordneten Attributdateien, migriert keinen bestehenden Verlauf zu LFS, bereinigt keine Objekte per Prune und lädt sie nicht automatisch hoch. Ein Muster konvertiert keine früheren Commits.

Ein Submodul auf einen bestimmten Stand aktualisieren

Wählen Sie im selben Panel ein Submodul und vergleichen Sie dessen aktuellen Commit mit dem im Index des übergeordneten Repositorys gespeicherten Commit. Prüfen Sie Initialisierung und ausstehende Änderungen vor der Aktualisierung.

Die Aktualisierung initialisiert bei Bedarf, ruft Daten ab und checkt den gespeicherten Commit mit Detached HEAD aus. Sie wechselt weder zum neuesten Remote-Branch-Stand noch ändert sie den im übergeordneten Repository gespeicherten Commit oder aktualisiert verschachtelte Submodule rekursiv. Geänderte oder unsichere Pfade und laufende Operationen werden abgelehnt. Öffnen Sie das Submodul als eigenen Riff-Kontext, um daran zu arbeiten.

Ein abgebrochener Abruf kann heruntergeladene Objekte oder ein teilweise initialisiertes Submodul zurücklassen. Lesen Sie vor einem erneuten Versuch den aktualisierten Zustand; Abbrechen bedeutet nicht, dass alle vorherigen Schritte rückgängig gemacht wurden.

Ein Identitäts- oder Signaturprofil anwenden

  1. Öffnen Sie die Repository-Identität und prüfen Sie den wirksamen Autor, die Konfigurationsquelle und die Organisationsrichtlinie. Wählen Sie die Git-Identität, das verfügbare Gapfy-Konto oder das von der Richtlinie erlaubte Standardverhalten.
  2. Speichern Sie ein benanntes Profil zur Wiederverwendung. Speichern oder Laden ändert das Repository nicht; prüfen und bestätigen Sie Anwenden separat.
  3. Wählen Sie bei Bedarf geerbte Signierung, OpenPGP oder SSH. Geben Sie eine Schlüsselkennung oder eine Referenz auf einen öffentlichen SSH-Schlüssel an. Riff importiert oder speichert keine privaten Signaturschlüssel. Das Abschalten der Signierung erfordert eine ausdrückliche Auswahl.
  4. Prüfen Sie den Zielbereich. Bei aktivierter Worktree-Konfiguration ändert Anwenden diesen Worktree, andernfalls die gemeinsam genutzte Repository-Konfiguration. Globale Konfiguration und eingebundene Dateien werden nicht überschrieben.
  5. Prüfen Sie die Signatur von HEAD. Das Ergebnis unterscheidet fehlenden Commit, unsignierten Commit, gültige und nicht verifizierte Signatur, ohne einen Test-Commit zu erstellen.

Die Identitätsrichtlinie der Organisation hat Vorrang vor einem Profil. Die Prüfung auf dem Computer beweist weder, dass der nächste Commit signiert werden kann, noch dass ein entfernter Host der Signatur vertraut. Konfigurieren Sie Werkzeug, Agent und Vertrauen separat nach den Anforderungen Ihrer Organisation.

Für abhängige Branches verwenden Sie Stacks und koordinierte Veröffentlichung. Für unabhängige Aufgaben nutzen Sie Arbeitskontexte und Worktrees.