Git School · FluxGit

Git worktree oder submodule: Entscheidung

FluxGit · 9. Oktober 2026

Die Blöcke sind verschiedene Fälle, kein Gesamtskript. Wähle den passenden Fall. Branchnamen, Pfade und VERIFIED_COMMIT vor Nutzung ersetzen. Abbruchbefehle gelten nur für ihre laufende Operation; nicht beide Alternativen ausführen.

Kurzantwort

Nutze worktree für einen weiteren Checkout desselben Repositories bei parallelen Aufgaben oder Branchprüfung. Nutze submodule, wenn das Elternrepository einen bestimmten Commit eines anderen als Abhängigkeit festhalten soll. Eines ergänzt ein Verzeichnis zum gemeinsamen Verlauf; das andere bindet separat versionierten Verlauf über eine gespeicherte Auswahl ein.

Entscheidung	Worktree	Submodule
Verlauf	Dasselbe Repository; geteilte Objekte und Referenzen	Eigenes Kindrepository; Parent hält einen Commit
Dateien	Eigenes HEAD, Index und Verzeichnis	Kindcheckout und Parent-/Index-Pins können abweichen
Version	Branch oder Commit desselben Repositories	Ausgewählter Kindcommit, nicht nur .gitmodules
Update	Gewählten Branch prüfen und integrieren	Checkout zum gespeicherten Pin; --remote ist andere Wahl
Grenze	Normalerweise ein Checkout je Branch; keine Rechtesandbox	Mehrere Worktrees unvollständig unterstützt; Kindarbeit getrennt

Beispiel und Voraussetzungen

Zuerst klären, wer den Verlauf besitzt. Zwei Agenten mit alternativen Anwendungsfixes brauchen meist getrennte Branches und Arbeitsverzeichnisse. Eine Bibliothek mit eigenen Releases kann eine fixierte Abhängigkeit benötigen. Beide sind keine Berechtigungssandbox: Dateisystem- und Agentenrechte bleiben separat zu steuern.

Vor Änderungen prüfen

Ein verknüpfter Worktree hat eigenes HEAD, Index und Dateien, teilt aber Objekte und die meisten Referenzen. So prüfst du einen anderen Branch, ohne deinen Checkout zu ersetzen. Git verhindert normalerweise denselben Branch in zwei Worktrees. Geteilte Objekte übertragen keine ungestagten Änderungen automatisch.

git status --short
git branch --show-current
git worktree list

Referenz oder getrennten Checkout behalten

Prüfe Status und erstelle review/worktree in ../topic-review. Mit git -C diesen Checkout und seine Commits vor gewählter Integration prüfen. Getrennte Verzeichnisse reduzieren Aufgabenvermischung, machen Änderungen aber nicht kompatibel. Integration testen und zwei gleichzeitig schreibende Werkzeuge im selben Checkout vermeiden.

git worktree add -b review/worktree ../topic-review HEAD
git -C ../topic-review status --short
git -C ../topic-review branch --show-current

Erster Ablauf

Ein Submodule ist ein eigenes Repository in einem Elternpfad. Der committete Elternbaum enthält einen gitlink, gewöhnlich Modus 160000, auf einen Kindcommit. Index und Kindcheckout können jeweils andere Commits benennen. .gitmodules beschreibt Pfad und URL; der gespeicherte Commit bestimmt die ausgewählte Version.

Anderes Ergebnis bewusst wählen

Für deps/library Submodule-Status, HEAD-gitlink des Elternrepositories, gestagten gitlink und Kind-HEAD getrennt prüfen. Parent-Pull kann den Pin ändern, ohne das Kind zu bewegen. Submodule update übernimmt die gespeicherte Auswahl; --remote folgt bewusst einer Remote-Auswahl. Das ist ein Versionsentscheid, kein bloßes Bereinigen des Status.

git submodule status -- deps/library
git ls-tree HEAD -- deps/library
git ls-files --stage -- deps/library
git -C deps/library rev-parse HEAD
git --no-optional-locks -C deps/library status --short

Grenzen und Ausnahmen

Git dokumentiert unvollständige Submodule-Unterstützung in mehreren Worktrees. --recursive macht nicht jede Kombination zu einer unterstützten isolierten Umgebung. Grenzen und tatsächlichen Checkout-/Updateablauf prüfen; für unabhängigen Zustand einen separaten Clone erwägen. Dies ist keine universelle Automatisierungsanleitung für die Kombination.

Konflikte und Aufräumen

Vor Worktree-Entfernung lokale Dateien und Branch prüfen, dann worktree remove statt blindem Ordnerlöschen nutzen. Gewünschten Branch oder geprüften Merge behalten. Vor Pinwechsel Kindänderung nach eigenem Prozess committen und veröffentlichen, damit andere Clones sie erhalten; danach den Pin im Elternrepository festhalten.

git -C ../topic-review status --short
git worktree remove ../topic-review
git worktree list

Ergebnis prüfen

Beim Worktree Branch, Status und Integration prüfen. Beim Submodule alle drei Zustände vergleichen und Abrufbarkeit des Kindobjekts für die Zielgruppe bestätigen. Ein sauberer Elternstatus garantiert keine sauberen Kindarbeitsverzeichnisse. Keines bewahrt uncommittete Dateien permanent; Prüfung folgt der Beziehung der Verläufe.

git worktree list
git submodule status -- deps/library

Häufige Fragen

Warum worktree? Anderer Branch ohne Checkoutwechsel. Wann submodule? Separat versionierte Abhängigkeit mit Parent-Pin. Warum vermeiden? Separate Update-Regeln kosten Koordination. Paketmanager, Vendoring, subtree oder eigener Clone sind je nach Versionshoheit und Auslieferung Alternativen, keine universellen Gewinner.

Operation in FluxGit prüfen

Prüfe die Operation und die betreffenden Commits mit FluxGits visuellem Verlauf und Patchansicht. Behalte die Prüfungen für Branch, geteilten Verlauf und lokale Dateien aus diesem Beispiel bei. Die Downloadseite zeigt die aktuell verfügbaren Builds und Plattformen.