English Version

Zurück zur Übersicht

git-sync-all: Sync-Ablauf

Repositories finden

Das Tool sucht mit find nach Verzeichnissen namens .git bis zur Tiefe SYNC_SCAN_DEPTH unter jedem Basisverzeichnis. Danach filtert es:

1. Include-Filter: Ist SYNC_INCLUDE gesetzt, muss der Verzeichnisname zu einem Muster passen.
2. Exclude-Filter: Passt der Verzeichnisname zu einem Muster aus SYNC_EXCLUDE, wird das Repository übersprungen.
3. Remote-Prüfung: Hat das Repository keinen Remote namens SYNC_REMOTE, wird es ohne Meldung übersprungen (nur mit -v sichtbar).

Nur echte .git-Verzeichnisse zählen. Worktrees und Submodule, bei denen .git eine Datei ist, werden nicht gefunden. Verschachtelte Repositories werden als eigene Repositories behandelt.

Ablauf pro Repository

graph TD
    A[Repository] --> B[Tags holen]
    B --> C[Zustand prüfen und Remote fetchen]
    C --> D{Änderungen im Arbeitsverzeichnis?}
    D -->|ja| E[Commit-Entscheidung]
    D -->|nein| F[Pull]
    E --> F
    F --> G[Push]
    G --> H[Ergebnis clean, synced, skipped oder failed]

1. Tags

Sofern Tags aktiv sind, ruft das Tool git fetch --tags --prune-tags <remote> auf. Fehler werden ignoriert. Das Tool pusht niemals Tags.

--prune-tags entfernt lokale Tags, die der Remote nicht kennt, nur dann, wenn Git auch das Pruning aktiv hat (fetch.prune=true oder remote.<name>.prune=true in deiner Git-Konfiguration). Dann gehen lokal angelegte, noch nicht gepushte Tags verloren. Ohne diese Einstellung bleibt der Befehl beim Holen neuer Tags. Mit --no-tags oder SYNC_TAGS=false entfällt der Schritt ganz.

2. Zustand prüfen

Ein Repository ist "dirty", wenn git status --porcelain etwas ausgibt. Das schließt nicht verfolgte Dateien ein. Ohne --no-pull führt das Tool git fetch <remote> <branch> für den aktuellen Branch aus und vergleicht HEAD mit dem Upstream (@{u}). Hat der Branch keinen Upstream, gibt es für das Tool nichts zu pullen und nichts zu pushen.

3. Änderungen im Arbeitsverzeichnis

Mit --yes entfällt die Rückfrage. Im Konfliktfall (Dateien lokal und remote geändert) entscheidet SYNC_CONFLICT_STRATEGY:

Ohne überlappende Dateien committet der Auto-Modus immer. Ohne Terminal und ohne --yes wird das Repository übersprungen.

Antwortest du mit q, meldet das Tool Aborted by user und beendet nur die Bearbeitung dieses Repositories. Es zählt als Failed, die weiteren Repositories werden noch abgearbeitet, und der Exit-Code ist 1.

4. Commit

Der Commit besteht aus git add -A und git commit -m <Nachricht> -m <Body>. git add -A nimmt alle Änderungen auf, auch nicht verfolgte Dateien, soweit .gitignore sie nicht ausschließt. Commit-Hooks laufen normal. Interaktiv kannst du die Nachricht überschreiben (Enter übernimmt die Vorgabe). Mit --yes oder ohne Terminal gilt die Vorlage aus SYNC_COMMIT_MSG.

5. Pull

Hat der Upstream neue Commits, führt das Tool git pull --rebase <remote> <branch> oder bei SYNC_PULL_STRATEGY=merge git pull <remote> <branch> aus. Schlägt der Pull fehl, bricht das Tool einen laufenden Rebase oder Merge selbst ab (git rebase --abort beziehungsweise git merge --abort), gibt die Git-Fehlermeldung eingerückt aus und zählt das Repository als Failed. Das Repository bleibt im Zustand vor dem Pull.

6. Push

Hat der Branch Commits vor dem Upstream, führt das Tool git push <remote> <branch> aus, ohne --force. Schlägt der Push fehl, zählt das Repository als Failed. Das Tool schaltet nie den Branch um, sondern arbeitet immer auf dem aktuellen.

Stash-Workflow

git stash push --include-untracked, dann Pull, dann git stash pop. Schlägt der Pull fehl, wird der Stash zurückgespielt. Gibt es beim Pop Konflikte, meldet das Tool dies und gibt den Hinweis, die Konflikte zu lösen und danach git stash drop auszuführen. Das Repository zählt dann als Failed.

Ergebnisse

Ein Fehler in einem Repository stoppt den Lauf nicht. Die übrigen Repositories werden weiter bearbeitet.