worktree

NAME名

git-worktree - Manage multiple working treesgit-worktree - 複数のワーキングツリーを管理する

SYNOPSIS概要

git worktree add [-f] [--detach] [--checkout] [--lock] [-b <new-branch>] <path> [<commit-ish>]
git worktree list [--porcelain]
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 unlock <worktree>

DESCRIPTION説明

Manage multiple working trees attached to the same repository.同じリポジトリにアタッチされている複数の作業ツリーを管理します。

A git repository can support multiple working trees, allowing you to check out more than one branch at a time. With git worktree add a new working tree is associated with the repository. This new working tree is called a "linked working tree" as opposed to the "main working tree" prepared by "git init" or "git clone". A repository has one main working tree (if it’s not a bare repository) and zero or more linked working trees. When you are done with a linked working tree, remove it with git worktree remove.Gitリポジトリは複数の作業ツリーをサポートすることができ、一度に複数のブランチをチェックアウトすることができます。でgit worktree add新しい作業ツリーリポジトリに関連付けられています。この新しいワーキングツリーは、 "git init"や "git clone"によって作成された "メインワーキングツリー"とは対照的に "リンクワーキングツリー"と呼ばれます。リポジトリには1つのメインワーキングツリー（ベアリポジトリではない場合）と0個以上のリンクされたワーキングツリーがあります。リンクされた作業ツリーを使い終わったら、で削除しgit worktree removeます。

If a working tree is deleted without using git worktree remove, then its associated administrative files, which reside in the repository (see "DETAILS" below), will eventually be removed automatically (see gc.worktreePruneExpire in git-config[1]), or you can run git worktree prune in the main or any linked working tree to clean up any stale administrative files.作業ツリーを使用せずに削除された場合git worktree remove、その後、最終的には自動的に削除されます、リポジトリ（以下、「詳細」を参照）に常駐その関連管理ファイルを、（参照gc.worktreePruneExpireして、[1]のgit-config設定）、またはあなたが実行することができますgit worktree pruneで古くなった管理ファイルを整理するためのメインまたはリンクされた作業ツリー。

If a linked working tree is stored on a portable device or network share which is not always mounted, you can prevent its administrative files from being pruned by issuing the git worktree lock command, optionally specifying --reason to explain why the working tree is locked.リンクされた作業ツリーが常にマウントされていないポータブルデバイスまたはネットワーク共有に保存されている場合は、git worktree lockコマンドを発行して管理ファイルが整理されないようにします--reason。

COMMANDSコマンド

add <path> [<commit-ish>] <path> [<commit-ish>]を追加

Create <path> and checkout <commit-ish> into it. The new working directory is linked to the current repository, sharing everything except working directory specific files such as HEAD, index, etc. - may also be specified as <commit-ish>; it is synonymous with @{-1}.それを作成<path>してチェックアウト<commit-ish>します。新しい作業ディレクトリは、などHEAD、インデックス、などの作業ディレクトリの特定のファイルを除いてすべてを共有し、現在のリポジトリにリンクされている-としても指定することができます<commit-ish>。と同義@{-1}です。

If <commit-ish> is a branch name (call it <branch>) and is not found, and neither -b nor -B nor --detach are used, but there does exist a tracking branch in exactly one remote (call it <remote>) with a matching name, treat as equivalent to:<コミットっぽい>場合は、ブランチ名である（それを呼び出す<branch>）と、検出されない、とどちら-bも-Bも--detach使用されているが、（それを呼び出すリモート正確に一つで追跡ブランチが存在しない<remote>と同等に扱い、一致する名前を持ちます）：

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

If the branch exists in multiple remotes and one of them is named by the checkout.defaultRemote configuration variable, we’ll use that one for the purposes of disambiguation, even if the <branch> isn’t unique across all remotes. Set it to e.g. checkout.defaultRemote=origin to always checkout remote branches from there if <branch> is ambiguous but exists on the origin remote. See also checkout.defaultRemote in git-config[1].ブランチが複数のリモートに存在し、そのうちの1つがcheckout.defaultRemote構成変数によって名前が付けられている場合、たとえそれが<branch>すべてのリモートにわたって一意でなくても、明確化の目的でそのブランチを使用します。あいまいではあるがリモートの起点に存在するcheckout.defaultRemote=origin場合<branch>は、常にそこからリモートブランチをチェックアウトするように設定します。参照してくださいにはgit-config設定[1] 。checkout.defaultRemote

If <commit-ish> is omitted and neither -b nor -B nor --detach used, then, as a convenience, the new worktree is associated with a branch (call it <branch>) named after $(basename <path>). If <branch> doesn’t exist, a new branch based on HEAD is automatically created as if -b <branch> was given. If <branch> does exist, it will be checked out in the new worktree, if it’s not checked out anywhere else, otherwise the command will refuse to create the worktree (unless --force is used).場合<commit-ish>とどちらも省略されて-bも-Bも--detach使用、そして、便利なように、新しいworktreeはブランチ（それを呼び出すと関連している<branch>にちなんで名付けられました）$(basename <path>)。<branch>存在しない場合は、HEADに基づいた新しいブランチが自動的に作成され-b <branch>ます。場合は<branch>存在しない、どこにもチェックアウトされていない場合は、それ以外のコマンドは（しない限り、worktreeを作成することを拒否します、新しいworktreeにチェックアウトされます--force使用されています）。

list リスト

List details of each worktree. The main worktree is listed first, followed by each of the linked worktrees. The output details include if the worktree is bare, the revision currently checked out, and the branch currently checked out (or detached HEAD if none).各ワークツリーの詳細を一覧表示します。メインワークツリーが最初にリストされ、その後にリンクされている各ワークツリーがリストされます。出力の詳細には、ワークツリーが裸であるかどうか、現在チェックアウトされているリビジョン、現在チェックアウトされているブランチ（存在しない場合は切り離されたHEAD）が含まれます。

lock ロック

If a working tree is on a portable device or network share which is not always mounted, lock it to prevent its administrative files from being pruned automatically. This also prevents it from being moved or deleted. Optionally, specify a reason for the lock with --reason.作業ツリーが常にマウントされていないポータブルデバイスまたはネットワーク共有上にある場合は、その管理ファイルが自動的に整理されないようにロックします。これにより、移動や削除もできなくなります。必要に応じて、でロックの理由を指定します--reason。

move 動く

Move a working tree to a new location. Note that the main working tree or linked working trees containing submodules cannot be moved.作業ツリーを新しい場所に移動します。サブモジュールを含むメインワーキングツリーまたはリンクワーキングツリーは移動できません。

prune プルーン

Prune working tree information in $GIT_DIR/worktrees.$ GIT_DIR / worktrees内の作業ツリー情報を整理します。

remove 削除する

Remove a working tree. Only clean working trees (no untracked files and no modification in tracked files) can be removed. Unclean working trees or ones with submodules can be removed with --force. The main working tree cannot be removed.作業ツリーを削除します。クリーンな作業ツリー（追跡されていないファイルや追跡されているファイルの変更がない）のみを削除できます。汚れた作業木やサブモジュールのある作業木は削除することができます--force。メイン作業ツリーは削除できません。

unlock ロック解除

Unlock a working tree, allowing it to be pruned, moved or deleted.作業ツリーのロックを解除して、剪定、移動、または削除できるようにします。

OPTIONSオプション

-f

--force - 力

By default, add refuses to create a new working tree when <commit-ish> is a branch name and is already checked out by another working tree, or if <path> is already assigned to some working tree but is missing (for instance, if <path> was deleted manually). This option overrides these safeguards. To add a missing but locked working tree path, specify --force twice.デフォルトでは、がブランチ名で、別の作業ツリーによってすでにチェックアウトされている場合、またはすでに作業ツリーに割り当てられているが欠落している場合（たとえば手動で削除された場合）はadd、新しい作業ツリーの作成を拒否します。このオプションはこれらの保護を無効にします。欠落しているがロックされている作業ツリーパスを追加するには、2回指定します。<commit-ish><path><path>--force

move refuses to move a locked working tree unless --force is specified twice.move--force二度指定されない限り、ロックされた作業ツリーを移動することを拒否します。

remove refuses to remove an unclean working tree unless --force is used. To remove a locked working tree, specify --force twice.remove--forceが使用されていない限り、汚れた作業ツリーを削除することを拒否します。ロックされた作業ツリーを削除するには、--force2回指定します。

-b <new-branch> -b <新しいブランチ>

-B <new-branch> -B <新規ブランチ>

With add, create a new branch named <new-branch> starting at <commit-ish>, and check out <new-branch> into the new working tree. If <commit-ish> is omitted, it defaults to HEAD. By default, -b refuses to create a new branch if it already exists. -B overrides this safeguard, resetting <new-branch> to <commit-ish>.でadd、名前の新しいブランチ作成<new-branch>から開始し<commit-ish>て、チェックアウト<new-branch>新しい作業ツリーへ。場合は<commit-ish>HEADに省略され、それがデフォルトになります。デフォルトでは-b、新しいブランチが既に存在する場合は作成を拒否します。-Bこの安全装置をオーバーライドし、にリセット<new-branch>し<commit-ish>ます。

--detach

With add, detach HEAD in the new working tree. See "DETACHED HEAD" in git-checkout[1].ではadd、新しい作業ツリーのHEADを切り離します。git-checkout [1]の "DETACHED HEAD"を参照してください。

--[no-]checkout - [no-]チェックアウト

By default, add checks out <commit-ish>, however, --no-checkout can be used to suppress checkout in order to make customizations, such as configuring sparse-checkout. See "Sparse checkout" in git-read-tree[1].ただし、デフォルトでは、addチェックアウトを使用して、疎チェックアウトの設定などのカスタマイズを行うためにチェックアウトを抑制することができます。git-read-tree [1]の "Sparse checkout"を参照してください。<commit-ish>--no-checkout

--[no-]guess-remote - [no-] guess-remote

With worktree add <path>, without <commit-ish>, instead of creating a new branch from HEAD, if there exists a tracking branch in exactly one remote matching the basename of <path>, base the new branch on the remote-tracking branch, and mark the remote-tracking branch as "upstream" from the new branch.worktree add <path>なしで<commit-ish>、代わりに正確に一つの遠隔のベース名に一致するトラッキング分岐が存在する場合、先頭から新しいブランチを作成する<path>、リモート追跡ブランチ上の新しいブランチをベースと、「上流」などのリモート追跡ブランチをマーク新しい枝から。

This can also be set up as the default behaviour by using the worktree.guessRemote config option.これは、worktree.guessRemoteconfigオプションを使用してデフォルトの動作として設定することもできます。

--[no-]track - [no-] track

When creating a new branch, if <commit-ish> is a branch, mark it as "upstream" from the new branch. This is the default if <commit-ish> is a remote-tracking branch. See "--track" in git-branch[1] for details.新しいブランチを作成するとき、それ<commit-ish>がブランチであれば、それを新しいブランチの「アップストリーム」としてマークします。が<commit-ish>リモート追跡ブランチの場合、これがデフォルトです。詳細はgit-branch [1]の "--track" を参照してください。

--lock - ロック

Keep the working tree locked after creation. This is the equivalent of git worktree lock after git worktree add, but without race condition.作成後は作業ツリーをロックしてください。これはgit worktree lockafter git worktree addと同等ですが、競合状態はありません。

-n

--dry-run

With prune, do not remove anything; just report what it would remove.でprune、何も削除しないでください。削除するものを報告するだけです。

--porcelain - 磁器

With list, output in an easy-to-parse format for scripts. This format will remain stable across Git versions and regardless of user configuration. See below for details.を使用するとlist、スクリプトを解析しやすい形式で出力できます。このフォーマットはGitのバージョン間でもユーザー設定に関係なく安定したままです。詳細は下記をご覧ください。

-q

--quiet - 静か

With add, suppress feedback messages.で追加、フィードバックメッセージを抑制する。

-v

--verbose - 冗談

With prune, report all removals.とprune、すべての削除を報告します。

--expire <time> --expire <時間>

With prune, only expire unused working trees older than <time>.でprune、<time>より古い未使用の作業ツリーのみを期限切れにします。

--reason <string> --reason <文字列>

With lock, an explanation why the working tree is locked.ではlock、なぜ作業ツリーがロックされているのか説明。

<worktree>

Working trees can be identified by path, either relative or absolute.作業ツリーは、相対パスまたは絶対パスのいずれかでパスによって識別できます。

If the last path components in the working tree’s path is unique among working trees, it can be used to identify worktrees. For example if you only have two working trees, at "/abc/def/ghi" and "/abc/def/ggg", then "ghi" or "def/ghi" is enough to point to the former working tree.作業ツリーのパスの最後のパスコンポーネントが作業ツリー間で一意である場合は、それを使用して作業ツリーを識別できます。たとえば、 "/ abc / def / ghi"と "/ abc / def / ggg"に2つの作業ツリーしかない場合は、 "ghi"または "def / ghi"で前の作業ツリーを指すことができます。

REFS

In multiple working trees, some refs may be shared between all working trees, some refs are local. One example is HEAD is different for all working trees. This section is about the sharing rules and how to access refs of one working tree from another.複数のワーキングツリーでは、すべてのワーキングツリー間で一部の参照が共有されることがあります。一部の参照はローカルです。一例として、HEADはすべての作業ツリーで異なります。このセクションでは、共有ルールと、ある作業ツリーの参照に別の参照からアクセスする方法について説明します。

In general, all pseudo refs are per working tree and all refs starting with "refs/" are shared. Pseudo refs are ones like HEAD which are directly under GIT_DIR instead of inside GIT_DIR/refs. There are one exception to this: refs inside refs/bisect and refs/worktree is not shared.一般に、すべての疑似参照は作業ツリーごとで、 "refs /"で始まるすべての参照は共有されます。疑似参照は、GIT_DIR / refsの内部ではなく、GIT_DIRの直下にあるHEADのようなものです。例外が1つあります。refs / bisectおよびrefs / worktreeの内側の参照は共有されません。

Refs that are per working tree can still be accessed from another working tree via two special paths, main-worktree and worktrees. The former gives access to per-worktree refs of the main working tree, while the latter to all linked working trees.作業ツリーごとの参照は、2つの特別なパス、main-worktreeおよびworktreesを介して別の作業ツリーからアクセスできます。前者はメイン作業ツリーの作業ツリーごとの参照へのアクセスを許可し、後者はすべてのリンクされた作業ツリーへのアクセスを許可します。

For example, main-worktree/HEAD or main-worktree/refs/bisect/good resolve to the same value as the main working tree’s HEAD and refs/bisect/good respectively. Similarly, worktrees/foo/HEAD or worktrees/bar/refs/bisect/bad are the same as GIT_COMMON_DIR/worktrees/foo/HEAD and GIT_COMMON_DIR/worktrees/bar/refs/bisect/bad.たとえば、main-worktree / HEADまたはmain-worktree / refs / bisect / goodは、それぞれメイン作業ツリーのHEADおよびrefs / bisect / goodと同じ値に解決されます。同様に、worktrees / foo / HEADまたはworktrees / bar / refs / bisect / badは、GIT_COMMON_DIR / worktrees / foo / HEADおよびGIT_COMMON_DIR / worktrees / bar / refs / bisect / badと同じです。

To access refs, it’s best not to look inside GIT_DIR directly. Instead use commands such as git-rev-parse[1] or git-update-ref[1] which will handle refs correctly.参照にアクセスするには、GIT_DIRの内部を直接見ないことが最善です。代わりに、git-rev-parse [1]やgit-update-ref [1]のような参照を正しく扱うコマンドを使ってください。

CONFIGURATION FILE設定ファイル

By default, the repository "config" file is shared across all working trees. If the config variables core.bare or core.worktree are already present in the config file, they will be applied to the main working trees only.デフォルトでは、リポジトリの "config"ファイルはすべての作業ツリーで共有されています。設定変数の場合core.bareやcore.worktree、設定ファイル内に既に存在している、彼らは唯一の主な作業の木に適用されます。

In order to have configuration specific to working trees, you can turn on "worktreeConfig" extension, e.g.:ワーキングツリー特有の設定をするために、 "worktreeConfig"拡張をオンにすることができます。例えば：

$ git config extensions.worktreeConfig true

In this mode, specific configuration stays in the path pointed by git rev-parse --git-path config.worktree. You can add or update configuration in this file with git config --worktree. Older Git versions will refuse to access repositories with this extension.このモードでは、特定の設定はで示されるパスに留まりますgit rev-parse --git-path config.worktree。このファイルの設定を追加または更新することができますgit config --worktree。古いGitバージョンはこの拡張子を持つリポジトリへのアクセスを拒否します。

Note that in this file, the exception for core.bare and core.worktree is gone. If you have them in $GIT_DIR/config before, you must move them to the config.worktree of the main working tree. You may also take this opportunity to review and move other configuration that you do not want to share to all working trees:このファイルには、例外ことに注意core.bareしてはcore.worktree消えています。あなたが以前にそれらを$ GIT_DIR / configに持っていたなら、あなたはそれらをconfig.worktreeメインワーキングツリーの中に移動しなければなりません。また、この機会に、共有したくない他の構成を検討してすべての作業ツリーに移動することもできます。

core.worktree and core.bare should never be sharedcore.worktreeそしてcore.bare決して共有されるべきではありません
core.sparseCheckout is recommended per working tree, unless you are sure you always use sparse checkout for all working trees.core.sparseCheckout すべての作業ツリーに対して常に疎チェックアウトを使用することが確実でない限り、作業ツリーごとに推奨されます。

DETAILS詳細

Each linked working tree has a private sub-directory in the repository’s $GIT_DIR/worktrees directory. The private sub-directory’s name is usually the base name of the linked working tree’s path, possibly appended with a number to make it unique. For example, when $GIT_DIR=/path/main/.git the command git worktree add /path/other/test-next next creates the linked working tree in /path/other/test-next and also creates a $GIT_DIR/worktrees/test-next directory (or $GIT_DIR/worktrees/test-next1 if test-next is already taken).リンクされた各作業ツリーは、リポジトリの$ GIT_DIR / worktreesディレクトリにプライベートサブディレクトリを持ちます。プライベートサブディレクトリの名前は通常、リンクされている作業ツリーのパスのベース名で、一意にするために番号が付加されている可能性があります。例えば$GIT_DIR=/path/main/.git、コマンドgit worktree add /path/other/test-next nextがにリンクされた作業ツリーを/path/other/test-next作成し、さらに$GIT_DIR/worktrees/test-nextディレクトリを作成する$GIT_DIR/worktrees/test-next1場合（またはtest-next既に作成されている場合）。

Within a linked working tree, $GIT_DIR is set to point to this private directory (e.g. /path/main/.git/worktrees/test-next in the example) and $GIT_COMMON_DIR is set to point back to the main working tree’s $GIT_DIR (e.g. /path/main/.git). These settings are made in a .git file located at the top directory of the linked working tree.リンクされたワーキングツリー内では、$ GIT_DIRはこのプライベートディレクトリを指すように設定され（例/path/main/.git/worktrees/test-nextでは）、$ GIT_COMMON_DIRはメインワーキングツリーの$ GIT_DIRを指すように設定されます（例えば/path/main/.git）。これらの設定は.git、リンクされた作業ツリーの最上位ディレクトリにあるファイルで行われます。

Path resolution via git rev-parse --git-path uses either $GIT_DIR or $GIT_COMMON_DIR depending on the path. For example, in the linked working tree git rev-parse --git-path HEAD returns /path/main/.git/worktrees/test-next/HEAD (not /path/other/test-next/.git/HEAD or /path/main/.git/HEAD) while git rev-parse --git-path refs/heads/master uses $GIT_COMMON_DIR and returns /path/main/.git/refs/heads/master, since refs are shared across all working trees, except refs/bisect and refs/worktree.パス解決via git rev-parse --git-pathは、パスに応じて$ GIT_DIRまたは$ GIT_COMMON_DIRを使用します。たとえば、リンクされた作業ツリーでは、$ GIT_COMMON_DIR を使用してgit rev-parse --git-path HEADリターンする/path/main/.git/worktrees/test-next/HEAD（not /path/other/test-next/.git/HEADor /path/main/.git/HEAD）一方、refはref / bisectおよびref / worktreeを除くすべてのワーキングツリーで共有されているためです。git rev-parse --git-path refs/heads/master/path/main/.git/refs/heads/master

See gitrepository-layout[5] for more information. The rule of thumb is do not make any assumption about whether a path belongs to $GIT_DIR or $GIT_COMMON_DIR when you need to directly access something inside $GIT_DIR. Use git rev-parse --git-path to get the final path.詳しくはgitrepository-layout [5]をご覧ください。経験則では、$ GIT_DIR内の何かに直接アクセスする必要がある場合、パスが$ GIT_DIRまたは$ GIT_COMMON_DIRのどちらに属しているかについては何も仮定しません。git rev-parse --git-path最終パスを取得するために使用します。

If you manually move a linked working tree, you need to update the gitdir file in the entry’s directory. For example, if a linked working tree is moved to /newpath/test-next and its .git file points to /path/main/.git/worktrees/test-next, then update /path/main/.git/worktrees/test-next/gitdir to reference /newpath/test-next instead.リンクした作業ツリーを手動で移動する場合は、エントリのディレクトリにあるgitdirファイルを更新する必要があります。たとえば、リンクされた作業ツリーがに移動され/newpath/test-next、その.gitファイルがポイントしている/path/main/.git/worktrees/test-next場合は、代わり/path/main/.git/worktrees/test-next/gitdirに参照/newpath/test-nextに更新します。

To prevent a $GIT_DIR/worktrees entry from being pruned (which can be useful in some situations, such as when the entry’s working tree is stored on a portable device), use the git worktree lock command, which adds a file named locked to the entry’s directory. The file contains the reason in plain text. For example, if a linked working tree’s .git file points to /path/main/.git/worktrees/test-next then a file named /path/main/.git/worktrees/test-next/locked will prevent the test-next entry from being pruned. See gitrepository-layout[5] for details.$ GIT_DIR / worktreesエントリが整理されないようにするには（エントリの作業ツリーがポータブルデバイスに保存されている場合など）、エントリのディレクトリにlockedgit worktree lockという名前のファイルを追加するコマンドを使用します。ファイルには理由がプレーンテキストで含まれています。たとえば、リンクされている作業ツリーのファイルがポイントしているファイルは、エントリが整理されないようにします。詳細はgitrepository-layout [5]をご覧ください。.git/path/main/.git/worktrees/test-next/path/main/.git/worktrees/test-next/lockedtest-next

When extensions.worktreeConfig is enabled, the config file .git/worktrees/<id>/config.worktree is read after .git/config is.extensions.worktreeConfigが有効になっていると、設定ファイル.git/worktrees/<id>/config.worktreeが読み込まれ.git/configます。

LIST OUTPUT FORMATリスト出力フォーマット

The worktree list command has two output formats. The default format shows the details on a single line with columns. For example:worktree listコマンドには2つの出力形式があります。デフォルトのフォーマットでは、詳細は列付きの単一行に表示されます。例えば：

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

Porcelain Format磁器フォーマット

The porcelain format has a line per attribute. Attributes are listed with a label and value separated by a single space. Boolean attributes (like bare and detached) are listed as a label only, and are only present if and only if the value is true. The first attribute of a worktree is always worktree, an empty line indicates the end of the record. For example:磁器フォーマットは属性ごとに1行あります。属性は、ラベルと値を1つのスペースで区切って表示されます。ブール属性（ベアやデタッチなど）はラベルとしてのみリストされ、値がtrueの場合にのみ存在します。ワークツリーの最初の属性は常にworktreeです。空行はレコードの終わりを示します。例えば：

$ 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

EXAMPLES例

You are in the middle of a refactoring session and your boss comes in and demands that you fix something immediately. You might typically use git-stash[1] to store your changes away temporarily, however, your working tree is in such a state of disarray (with new, moved, and removed files, and other bits and pieces strewn around) that you don’t want to risk disturbing any of it. Instead, you create a temporary linked working tree to make the emergency fix, remove it when done, and then resume your earlier refactoring session.あなたはリファクタリングセッションの最中にあり、上司がやって来てすぐに何かを直すことを要求します。通常、git-stash [1]を使用して変更を一時的に保存することができますが、作業ツリーは混乱した状態（新しいファイル、移動したファイル、削除したファイル、その他の断片）になっています。それを邪魔する危険を冒したくない。代わりに、緊急修正を行い、完了したらそれを削除してから、以前のリファクタリングセッションを再開するために一時的にリンクされた作業ツリーを作成します。

$ 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

BUGSバグ

Multiple checkout in general is still experimental, and the support for submodules is incomplete. It is NOT recommended to make multiple checkouts of a superproject.一般的な多重チェックアウトはまだ実験的なもので、サブモジュールのサポートは不完全です。スーパープロジェクトを複数回チェックアウトすることはお勧めできません。