English ▾ Themen ▾ Neueste Version ▾ git-worktree zuletzt aktualisiert in 2.52.0

NAME

git-worktree - Mehrere Arbeitsbäume verwalten

SYNOPSIS

git worktree add [-f] [--detach] [--checkout] [--lock [--reason <string>]]
		 [--orphan] [(-b | -B) <new-branch>] <path> [<commit-ish>]
git worktree list [-v | --porcelain [-z]]
git worktree lock [--reason <string>] <worktree>
git worktree move <worktree> <new-path>
git worktree prune [-n] [-v] [--expire <expire>]
git worktree remove [-f] <worktree>
git worktree repair [<path>…​]
git worktree unlock <worktree>

BESCHREIBUNG

Mehrere Arbeitsbäume, die mit demselben Repository verbunden sind, verwalten.

Ein Git-Repository kann mehrere Arbeitsbäume unterstützen, sodass Sie mehr als einen Branch gleichzeitig auschecken können. Mit git worktree add wird ein neuer Arbeitsbaum mit dem Repository verknüpft, zusammen mit zusätzlichen Metadaten, die diesen Arbeitsbaum von anderen im selben Repository unterscheiden. Der Arbeitsbaum zusammen mit diesen Metadaten wird als "Worktree" bezeichnet.

Dieser neue Worktree wird als "verknüpfter Worktree" bezeichnet, im Gegensatz zum "Haupt-Worktree", der von git-init[1] oder git-clone[1] vorbereitet wird. Ein Repository hat einen Haupt-Worktree (sofern es kein Bare-Repository ist) und null oder mehr verknüpfte Worktrees. Wenn Sie mit einem verknüpften Worktree fertig sind, entfernen Sie ihn mit git worktree remove.

In seiner einfachsten Form erstellt git worktree add <Pfad> automatisch einen neuen Branch, dessen Name die letzte Komponente von <Pfad> ist. Dies ist praktisch, wenn Sie an einem neuen Thema arbeiten möchten. Zum Beispiel erstellt git worktree add ../hotfix einen neuen Branch hotfix und checkt ihn unter dem Pfad ../hotfix aus. Um stattdessen an einem vorhandenen Branch in einem neuen Worktree zu arbeiten, verwenden Sie git worktree add <Pfad> <Branch>. Wenn Sie andererseits nur einige experimentelle Änderungen vornehmen oder Tests durchführen möchten, ohne die vorhandene Entwicklung zu stören, ist es oft praktisch, einen "Wegwerf"-Worktree zu erstellen, der keinem Branch zugeordnet ist. Zum Beispiel erstellt git worktree add -d <Pfad> einen neuen Worktree mit einem gelösten HEAD auf demselben Commit wie der aktuelle Branch.

Wenn ein Arbeitsbaum ohne Verwendung von git worktree remove gelöscht wird, werden seine zugehörigen Verwaltungsdateien, die sich im Repository befinden (siehe "DETAILS" unten), irgendwann automatisch entfernt (siehe gc.worktreePruneExpire in git-config[1]), oder Sie können git worktree prune im Haupt-Worktree oder in einem verknüpften Worktree ausführen, um veraltete Verwaltungsdateien zu bereinigen.

Wenn der Arbeitsbaum für einen verknüpften Worktree auf einem portablen Gerät oder einer Netzwerkfreigabe gespeichert ist, die nicht immer gemountet ist, können Sie verhindern, dass seine Verwaltungsdateien gelöscht werden, indem Sie den Befehl git worktree lock ausführen und optional --reason angeben, um zu erklären, warum der Worktree gesperrt ist.

BEFEHLE

add <Pfad> [<Commit-Referenz>]

Erstellt einen Arbeitsbaum unter <Pfad> und checkt <Commit-Referenz> darin aus. Der neue Arbeitsbaum ist mit dem aktuellen Repository verknüpft und teilt alles außer worktree-spezifischen Dateien wie HEAD, index usw. Als Vereinfachung kann <Commit-Referenz> ein bloßer "-" sein, was synonym mit @{-1} ist.

Wenn <Commit-Referenz> ein Branch-Name ist (nennen wir ihn <Branch>) und nicht gefunden wird, und weder -b noch -B noch --detach verwendet werden, aber ein Tracking-Branch auf genau einem Remote (nennen wir ihn <Remote>) mit übereinstimmendem Namen existiert, behandeln Sie ihn als äquivalent zu

$ git worktree add --track -b <branch> <path> <remote>/<branch>

Wenn der Branch auf mehreren Remotes existiert und einer davon durch die Konfigurationsvariable checkout.defaultRemote benannt ist, verwenden wir diesen zur Disambiguierung, auch wenn <Branch> nicht eindeutig über alle Remotes hinweg ist. Setzen Sie ihn z. B. auf checkout.defaultRemote=origin, um immer Remote-Branches von dort auszuchecken, wenn <Branch> mehrdeutig, aber auf dem origin-Remote vorhanden ist. Siehe auch checkout.defaultRemote in git-config[1].

Wenn <Commit-Referenz> weggelassen wird und weder -b noch -B noch --detach verwendet werden, wird der neue Worktree als Vereinfachung einem Branch (nennen wir ihn <Branch>) zugeordnet, der nach $(basename <Pfad>) benannt ist. Wenn <Branch> nicht existiert, wird ein neuer Branch basierend auf HEAD automatisch erstellt, als ob -b <Branch> angegeben worden wäre. Wenn <Branch> existiert, wird er im neuen Worktree ausgecheckt, wenn er nirgendwo sonst ausgecheckt ist, andernfalls weigert sich der Befehl, den Worktree zu erstellen (es sei denn, --force wird verwendet).

Wenn <Commit-Referenz> weggelassen wird, weder --detach noch --orphan verwendet werden und keine gültigen lokalen Branches (oder Remote-Branches, wenn --guess-remote angegeben ist) vorhanden sind, dann wird als Vereinfachung der neue Worktree einem neuen, ungeborenen Branch namens <Branch> zugeordnet (nach $(basename <Pfad>), wenn weder -b noch -B verwendet werden), als ob --orphan an den Befehl übergeben worden wäre. Falls das Repository ein Remote hat und --guess-remote verwendet wird, aber keine Remote- oder lokalen Branches existieren, schlägt der Befehl mit einer Warnung fehl, die den Benutzer auffordert, zuerst vom Remote abzurufen (oder durch die Verwendung von -f/--force zu überschreiben).

list

Listet Details zu jedem Arbeitsbaum auf. Der Hauptarbeitsbaum wird zuerst aufgelistet, gefolgt von jedem der verknüpften Arbeitsbäume. Die Ausgabe details umfassen, ob der Arbeitsbaum leer ist, die aktuell ausgecheckte Revision, den aktuell ausgecheckten Branch (oder "detached HEAD", falls keiner), "locked", wenn der Arbeitsbaum gesperrt ist, "prunable", wenn der Arbeitsbaum mit dem Befehl prune gelöscht werden kann.

lock

Wenn sich ein Arbeitsbaum auf einem portablen Gerät oder einer Netzwerkfreigabe befindet, die nicht immer gemountet ist, sperren Sie ihn, um zu verhindern, dass seine Verwaltungsdateien automatisch gelöscht werden. Dies verhindert auch, dass er verschoben oder gelöscht wird. Optional können Sie mit --reason einen Grund für die Sperrung angeben.

move

Verschiebt einen Arbeitsbaum an einen neuen Ort. Beachten Sie, dass der Hauptarbeitsbaum oder verknüpfte Arbeitsbäume, die Submodule enthalten, mit diesem Befehl nicht verschoben werden können. (Der Befehl git worktree repair kann jedoch die Verbindung zu verknüpften Arbeitsbäumen wiederherstellen, wenn Sie den Hauptarbeitsbaum manuell verschieben.)

prune

Bereinigt die Worktree-Informationen in $GIT_DIR/worktrees.

remove

Entfernt einen Arbeitsbaum. Nur saubere Arbeitsbäume (keine ungetrackten Dateien und keine Änderungen an getrackten Dateien) können entfernt werden. Unsaubere Arbeitsbäume oder solche mit Submodulen können mit --force entfernt werden. Der Hauptarbeitsbaum kann nicht entfernt werden.

repair [<Pfad>...]

Repariert die Verwaltungsdateien des Arbeitsbaums, falls möglich, wenn diese durch externe Faktoren beschädigt oder veraltet sind.

Wenn beispielsweise der Hauptarbeitsbaum (oder ein Bare-Repository) verschoben wird, können verknüpfte Arbeitsbäume ihn nicht finden. Das Ausführen von repair im Hauptarbeitsbaum stellt die Verbindung von verknüpften Arbeitsbäumen zum Hauptarbeitsbaum wieder her.

Ebenso, wenn der Arbeitsbaum eines verknüpften Arbeitsbaums ohne Verwendung von git worktree move verschoben wird, kann der Hauptarbeitsbaum (oder das Bare-Repository) ihn nicht finden. Das Ausführen von repair im kürzlich verschobenen Arbeitsbaum stellt die Verbindung wieder her. Wenn mehrere verknüpfte Arbeitsbäume verschoben wurden, stellt das Ausführen von repair von einem beliebigen Arbeitsbaum aus mit dem neuen <Pfad> jedes Baums als Argument die Verbindung zu allen angegebenen Pfaden wieder her.

Wenn sowohl der Hauptarbeitsbaum als auch die verknüpften Arbeitsbäume manuell verschoben oder kopiert wurden, stellt das Ausführen von repair im Hauptarbeitsbaum und die Angabe des neuen <Pfad> jedes verknüpften Arbeitsbaums die Verbindungen in beide Richtungen wieder her.

unlock

Entsperrt einen Arbeitsbaum und ermöglicht dessen Löschen, Verschieben oder Entfernen.

OPTIONEN

-f
--force

Standardmäßig weigert sich add, einen neuen Arbeitsbaum zu erstellen, wenn <Commit-Referenz> ein Branch-Name ist und bereits von einem anderen Arbeitsbaum ausgecheckt wurde, oder wenn <Pfad> bereits einem Arbeitsbaum zugeordnet ist, aber fehlt (z. B. wenn <Pfad> manuell gelöscht wurde). Diese Option überschreibt diese Schutzmaßnahmen. Um einen fehlenden, aber gesperrten Arbeitsbaum-Pfad hinzuzufügen, geben Sie --force zweimal an.

move weigert sich, einen gesperrten Arbeitsbaum zu verschieben, es sei denn, --force wird zweimal angegeben. Wenn das Ziel bereits einem anderen Arbeitsbaum zugeordnet ist, aber fehlt (z. B. wenn <neuer-Pfad> manuell gelöscht wurde), erlaubt --force das Verschieben. Verwenden Sie --force zweimal, wenn das Ziel gesperrt ist.

remove weigert sich, einen unsauberen Arbeitsbaum zu entfernen, es sei denn, --force wird verwendet. Um einen gesperrten Arbeitsbaum zu entfernen, geben Sie --force zweimal an.

-b <neuer-Branch>
-B <neuer-Branch>

Mit add erstellen Sie einen neuen Branch namens <neuer-Branch>, beginnend bei <Commit-Referenz>, und checken Sie <neuer-Branch> in den neuen Arbeitsbaum aus. Wenn <Commit-Referenz> weggelassen wird, ist der Standardwert HEAD. Standardmäßig weigert sich -b, einen neuen Branch zu erstellen, wenn er bereits existiert. -B überschreibt diese Schutzmaßnahme und setzt <neuer-Branch> auf <Commit-Referenz> zurück.

-d
--detach

Mit add wird HEAD im neuen Arbeitsbaum gelöst. Siehe "DETACHED HEAD" in git-checkout[1].

--checkout
--no-checkout

Standardmäßig checkt add <Commit-Referenz> aus. --no-checkout kann jedoch verwendet werden, um das Auschecken zu unterdrücken, um Anpassungen vorzunehmen, z. B. Sparse-Checkout zu konfigurieren. Siehe "Sparse checkout" in git-read-tree[1].

--guess-remote
--no-guess-remote

Mit worktree add <Pfad>, ohne <Commit-Referenz>, wird anstatt einen neuen Branch von HEAD zu erstellen, wenn ein Tracking-Branch auf genau einem Remote existiert, der mit dem Basisnamen von <Pfad> übereinstimmt, der neue Branch auf den Remote-Tracking-Branch basieren und der Remote-Tracking-Branch als "Upstream" des neuen Branches markiert werden.

Dies kann auch als Standardverhalten eingerichtet werden, indem die Konfigurationsoption worktree.guessRemote verwendet wird.

--relative-paths
--no-relative-paths

Verknüpft Arbeitsbäume mit relativen oder absoluten Pfaden (Standard). Überschreibt die Konfigurationsoption worktree.useRelativePaths, siehe git-config[1].

Bei repair werden die Verknüpfungsdateien aktualisiert, wenn ein absoluter/relativer Abgleich vorliegt, auch wenn die Links korrekt sind.

--track
--no-track

Beim Erstellen eines neuen Branches, wenn <Commit-Referenz> ein Branch ist, markieren Sie ihn als "Upstream" des neuen Branches. Dies ist der Standard, wenn <Commit-Referenz> ein Remote-Tracking-Branch ist. Siehe --track in git-branch[1] für Details.

--lock

Hält den Arbeitsbaum nach der Erstellung gesperrt. Dies ist das Äquivalent von git worktree lock nach git worktree add, jedoch ohne Race Condition.

-n
--dry-run

Mit prune wird nichts entfernt; es wird nur berichtet, was entfernt werden würde.

--orphan

Mit add werden der neue Arbeitsbaum und der Index leer gemacht und der Arbeitsbaum mit einem neuen, ungeborenen Branch namens <neuer-Branch> verknüpft.

--porcelain

Mit list wird die Ausgabe in einem leicht zu parsenden Format für Skripte ausgegeben. Dieses Format bleibt über Git-Versionen hinweg und unabhängig von der Benutzerkonfiguration stabil. Es wird empfohlen, dies mit -z zu kombinieren. Einzelheiten siehe unten.

-z

Beendet jede Zeile mit einem NUL-Zeichen anstelle eines Zeilenumbruchs, wenn --porcelain zusammen mit list angegeben wird. Dies ermöglicht das Parsen der Ausgabe, wenn ein Arbeitsbaum-Pfad ein Zeilenumbruchzeichen enthält.

-q
--quiet

Mit add werden Feedback-Meldungen unterdrückt.

-v
--verbose

Mit prune werden alle Entfernungen gemeldet.

Mit list werden zusätzliche Informationen zu Arbeitsbäumen ausgegeben (siehe unten).

--expire <Zeit>

Mit prune werden nur ungenutzte Arbeitsbäume, die älter als <Zeit> sind, abgelaufen.

Mit list werden fehlende Arbeitsbäume als löschbar annotiert, wenn sie älter als <Zeit> sind.

--reason <Zeichenkette>

Mit lock oder mit add --lock eine Erklärung, warum der Arbeitsbaum gesperrt ist.

<Worktree>

Arbeitsbäume können anhand ihres Pfades identifiziert werden, entweder relativ oder absolut.

Wenn die letzten Pfadkomponenten im Pfad des Arbeitsbaums unter den Arbeitsbäumen eindeutig sind, können sie zur Identifizierung eines Arbeitsbaums verwendet werden. Wenn Sie beispielsweise nur zwei Arbeitsbäume unter /abc/def/ghi und /abc/def/ggg haben, dann reicht ghi oder def/ghi aus, um auf den ersteren Arbeitsbaum zu verweisen.

REFS

Bei der Verwendung mehrerer Arbeitsbäume werden einige Refs zwischen allen Arbeitsbäumen geteilt, andere sind jedoch spezifisch für einen einzelnen Arbeitsbaum. Ein Beispiel ist HEAD, das für jeden Arbeitsbaum unterschiedlich ist. Dieser Abschnitt befasst sich mit den Freigaberegeln und dem Zugriff auf Refs eines Arbeitsbaums von einem anderen aus.

Im Allgemeinen sind alle Pseudorefs pro Arbeitsbaum und alle Refs, die mit refs/ beginnen, gemeinsam genutzt. Pseudorefs sind solche wie HEAD, die sich direkt unter $GIT_DIR anstatt innerhalb von $GIT_DIR/refs befinden. Es gibt jedoch Ausnahmen: Refs innerhalb von refs/bisect, refs/worktree und refs/rewritten werden nicht geteilt.

Refs, die pro Arbeitsbaum spezifisch sind, können von einem anderen Arbeitsbaum über zwei spezielle Pfade, main-worktree und worktrees, angesprochen werden. Der erstere bietet Zugriff auf die pro Arbeitsbaum spezifischen Refs des Hauptarbeitsbaums, während der letztere auf alle verknüpften Arbeitsbäume zugreift.

Zum Beispiel entsprechen main-worktree/HEAD oder main-worktree/refs/bisect/good denselben Werten wie der HEAD und refs/bisect/good des Hauptarbeitsbaums. Ebenso entsprechen worktrees/foo/HEAD oder worktrees/bar/refs/bisect/bad $GIT_COMMON_DIR/worktrees/foo/HEAD und $GIT_COMMON_DIR/worktrees/bar/refs/bisect/bad.

Um auf Refs zuzugreifen, ist es am besten, nicht direkt in $GIT_DIR nachzusehen. Verwenden Sie stattdessen Befehle wie git-rev-parse[1] oder git-update-ref[1], die Refs korrekt behandeln.

KONFIGURATIONSFEIL

Standardmäßig wird die Konfigurationsdatei des Repositorys über alle Arbeitsbäume hinweg geteilt. Wenn die Konfigurationsvariablen core.bare oder core.worktree in der gemeinsamen Konfigurationsdatei vorhanden sind und extensions.worktreeConfig deaktiviert ist, werden sie nur auf den Hauptarbeitsbaum angewendet.

Um eine arbeitsbaum-spezifische Konfiguration zu haben, können Sie die Erweiterung worktreeConfig aktivieren, z. B.:

$ git config extensions.worktreeConfig true

In diesem Modus verbleibt die spezifische Konfiguration im Pfad, auf den von git rev-parse --git-path config.worktree verwiesen wird. Sie können Konfigurationen in dieser Datei mit git config --worktree hinzufügen oder aktualisieren. Ältere Git-Versionen lehnen den Zugriff auf Repositorys mit dieser Erweiterung ab.

Beachten Sie, dass in dieser Datei die Ausnahme für core.bare und core.worktree entfällt. Wenn sie in $GIT_DIR/config vorhanden sind, müssen Sie sie in die config.worktree des Hauptarbeitsbaums verschieben. Sie können auch diese Gelegenheit nutzen, um andere Konfigurationen zu überprüfen und zu verschieben, die Sie nicht mit allen Arbeitsbäumen teilen möchten.

  • core.worktree sollte niemals geteilt werden.

  • core.bare sollte nicht geteilt werden, wenn der Wert core.bare=true ist.

  • core.sparseCheckout sollte nicht geteilt werden, es sei denn, Sie sind sicher, dass Sie immer Sparse-Checkout für alle Arbeitsbäume verwenden.

Weitere Informationen finden Sie in der Dokumentation zu extensions.worktreeConfig in git-config[1].

DETAILS

Jeder verknüpfte Arbeitsbaum hat ein privates Unterverzeichnis im Verzeichnis $GIT_DIR/worktrees des Repositorys. Der Name des privaten Unterverzeichnisses ist normalerweise der Basisname des Pfads des verknüpften Arbeitsbaums, möglicherweise mit einer Zahl angehängt, um ihn eindeutig zu machen. Wenn beispielsweise $GIT_DIR=/pfad/main/.git und der Befehl git worktree add /pfad/other/test-next next ausgeführt wird, wird der verknüpfte Arbeitsbaum unter /pfad/other/test-next erstellt und auch ein Verzeichnis $GIT_DIR/worktrees/test-next (oder $GIT_DIR/worktrees/test-next1, wenn test-next bereits belegt ist).

Innerhalb eines verknüpften Arbeitsbaums wird $GIT_DIR so gesetzt, dass es auf dieses private Verzeichnis zeigt (z. B. /pfad/main/.git/worktrees/test-next im Beispiel) und $GIT_COMMON_DIR wird so gesetzt, dass es zurück auf das $GIT_DIR des Hauptarbeitsbaums zeigt (z. B. /pfad/main/.git). Diese Einstellungen werden in einer Datei .git im Stammverzeichnis des verknüpften Arbeitsbaums vorgenommen.

Die Pfadauflösung über git rev-parse --git-path verwendet entweder $GIT_DIR oder $GIT_COMMON_DIR, abhängig vom Pfad. Zum Beispiel gibt in dem verknüpften Arbeitsbaum git rev-parse --git-path HEAD /pfad/main/.git/worktrees/test-next/HEAD zurück (nicht /pfad/other/test-next/.git/HEAD oder /pfad/main/.git/HEAD), während git rev-parse --git-path refs/heads/master $GIT_COMMON_DIR verwendet und /pfad/main/.git/refs/heads/master zurückgibt, da Refs über alle Arbeitsbäume hinweg geteilt werden, außer refs/bisect, refs/worktree und refs/rewritten.

Siehe gitrepository-layout[5] für weitere Informationen. Die Faustregel lautet, keine Annahmen darüber zu treffen, ob ein Pfad zu $GIT_DIR oder $GIT_COMMON_DIR gehört, wenn Sie direkt auf etwas innerhalb von $GIT_DIR zugreifen müssen. Verwenden Sie git rev-parse --git-path, um den endgültigen Pfad zu erhalten.

Wenn Sie einen verknüpften Arbeitsbaum manuell verschieben, müssen Sie die Datei gitdir im Verzeichnis des Eintrags aktualisieren. Wenn beispielsweise ein verknüpfter Arbeitsbaum nach /neuerpfad/test-next verschoben wird und seine Datei .git auf /pfad/main/.git/worktrees/test-next zeigt, aktualisieren Sie /pfad/main/.git/worktrees/test-next/gitdir so, dass sie stattdessen auf /neuerpfad/test-next verweist. Besser noch, führen Sie git worktree repair aus, um die Verbindung automatisch wiederherzustellen.

Um zu verhindern, dass ein $GIT_DIR/worktrees-Eintrag gelöscht wird (was in einigen Situationen nützlich sein kann, z. B. wenn der entsprechende Arbeitsbaum auf einem portablen Gerät gespeichert ist), verwenden Sie den Befehl git worktree lock, der eine Datei namens locked zum Verzeichnis des Eintrags hinzufügt. Die Datei enthält den Grund in Klartext. Wenn beispielsweise die .git-Datei eines verknüpften Arbeitsbaums auf /pfad/main/.git/worktrees/test-next zeigt, verhindert eine Datei namens /pfad/main/.git/worktrees/test-next/locked, dass der test-next-Eintrag gelöscht wird. Siehe gitrepository-layout[5] für Details.

Wenn extensions.worktreeConfig aktiviert ist, wird die Konfigurationsdatei .git/worktrees/<id>/config.worktree nach .git/config gelesen.

LIST AUSGABEFORMAT

Der Befehl worktree list hat zwei Ausgabeformate. Das Standardformat zeigt die Details auf einer einzigen Zeile mit Spalten. Zum Beispiel

$ git worktree list
/path/to/bare-source            (bare)
/path/to/linked-worktree        abcd1234 [master]
/path/to/other-linked-worktree  1234abc  (detached HEAD)

Der Befehl zeigt auch Anmerkungen für jeden Arbeitsbaum entsprechend seinem Status an. Diese Anmerkungen sind:

  • locked, wenn der Arbeitsbaum gesperrt ist.

  • prunable, wenn der Arbeitsbaum über git worktree prune gelöscht werden kann.

$ git worktree list
/path/to/linked-worktree    abcd1234 [master]
/path/to/locked-worktree    acbd5678 (brancha) locked
/path/to/prunable-worktree  5678abc  (detached HEAD) prunable

Für diese Anmerkungen kann auch ein Grund verfügbar sein, der im ausführlichen Modus angezeigt werden kann. Die Anmerkung wird dann in die nächste Zeile verschoben, eingerückt und gefolgt von zusätzlichen Informationen.

$ git worktree list --verbose
/path/to/linked-worktree              abcd1234 [master]
/path/to/locked-worktree-no-reason    abcd5678 (detached HEAD) locked
/path/to/locked-worktree-with-reason  1234abcd (brancha)
	locked: worktree path is mounted on a portable device
/path/to/prunable-worktree            5678abc1 (detached HEAD)
	prunable: gitdir file points to non-existent location

Beachten Sie, dass die Anmerkung in die nächste Zeile verschoben wird, wenn zusätzliche Informationen verfügbar sind, andernfalls bleibt sie in derselben Zeile wie der Arbeitsbaum selbst.

Porcelain-Format

Das Porcelain-Format hat eine Zeile pro Attribut. Wenn -z angegeben wird, werden die Zeilen mit NUL anstelle eines Zeilenumbruchs beendet. Attribute werden mit einer Bezeichnung und einem Wert angezeigt, die durch ein einzelnes Leerzeichen getrennt sind. Boolesche Attribute (wie bare und detached) werden nur als Bezeichnung aufgeführt und sind nur vorhanden, wenn der Wert wahr ist. Einige Attribute (wie locked) können nur als Bezeichnung oder mit einem Wert aufgeführt werden, je nachdem, ob ein Grund verfügbar ist. Das erste Attribut eines Arbeitsbaums ist immer worktree, eine leere Zeile kennzeichnet das Ende des Datensatzes. Zum Beispiel

$ git worktree list --porcelain
worktree /path/to/bare-source
bare

worktree /path/to/linked-worktree
HEAD abcd1234abcd1234abcd1234abcd1234abcd1234
branch refs/heads/master

worktree /path/to/other-linked-worktree
HEAD 1234abc1234abc1234abc1234abc1234abc1234a
detached

worktree /path/to/linked-worktree-locked-no-reason
HEAD 5678abc5678abc5678abc5678abc5678abc5678c
branch refs/heads/locked-no-reason
locked

worktree /path/to/linked-worktree-locked-with-reason
HEAD 3456def3456def3456def3456def3456def3456b
branch refs/heads/locked-with-reason
locked reason why is locked

worktree /path/to/linked-worktree-prunable
HEAD 1233def1234def1234def1234def1234def1234b
detached
prunable gitdir file points to non-existent location

Wenn nicht -z verwendet wird, werden "ungewöhnliche" Zeichen in der Sperrbegründung, wie z. B. Zeilenumbrüche, maskiert und die gesamte Begründung wird wie für die Konfigurationsvariable core.quotePath erklärt (siehe git-config[1]). Zum Beispiel

$ git worktree list --porcelain
...
locked "reason\nwhy is locked"
...

BEISPIELE

Sie befinden sich mitten in einer Refactoring-Sitzung und Ihr Chef kommt herein und verlangt, dass Sie sofort etwas reparieren. Sie würden normalerweise git-stash[1] verwenden, um Ihre Änderungen vorübergehend zu speichern. Da Ihr Arbeitsverzeichnis jedoch in einem so chaotischen Zustand ist (mit neuen, verschobenen und entfernten Dateien sowie anderen verstreuten Elementen), möchten Sie kein Risiko eingehen, etwas davon zu stören. Stattdessen erstellen Sie ein temporäres verknüpftes Arbeitsverzeichnis, um die dringende Korrektur vorzunehmen, entfernen es, wenn Sie fertig sind, und setzen dann Ihre frühere Refactoring-Sitzung fort.

$ git worktree add -b emergency-fix ../temp master
$ pushd ../temp
# ... hack hack hack ...
$ git commit -a -m 'emergency fix for boss'
$ popd
$ git worktree remove ../temp

KONFIGURATION

Alles unterhalb dieser Zeile in diesem Abschnitt wird selektiv aus der git-config[1]-Dokumentation übernommen. Der Inhalt ist derselbe wie dort zu finden.

worktree.guessRemote

Wenn kein Branch angegeben ist und weder -b noch -B noch --detach verwendet wird, erstellt git worktree add standardmäßig einen neuen Branch von HEAD. Wenn worktree.guessRemote auf true gesetzt ist, versucht worktree add, einen Remote-Tracking-Branch zu finden, dessen Name eindeutig mit dem Namen des neuen Branches übereinstimmt. Wenn ein solcher Branch existiert, wird er ausgecheckt und als "Upstream" für den neuen Branch gesetzt. Wenn keine solche Übereinstimmung gefunden wird, wird stattdessen ein neuer Branch vom aktuellen HEAD erstellt.

worktree.useRelativePaths

Verknüpft Arbeitsverzeichnisse mithilfe von relativen Pfaden (wenn "true") oder absoluten Pfaden (wenn "false"). Dies ist besonders nützlich für Setups, bei denen das Repository und die Arbeitsverzeichnisse zwischen verschiedenen Orten oder Umgebungen verschoben werden können. Standardmäßig ist dies "false".

Beachten Sie, dass das Setzen von worktree.useRelativePaths auf "true" das Aktivieren der extensions.relativeWorktrees-Konfiguration (siehe git-config[1]) impliziert und somit inkompatibel mit älteren Git-Versionen ist.

BUGS

Mehrere Checkouts sind im Allgemeinen noch experimentell, und die Unterstützung für Submodule ist unvollständig. Es wird NICHT empfohlen, mehrere Checkouts eines Superprojekts vorzunehmen.

GIT

Teil der git[1] Suite