| 1 | git-worktree(1) |
| 2 | =============== |
| 3 | |
| 4 | NAME |
| 5 | ---- |
| 6 | git-worktree - Manage multiple working trees |
| 7 | |
| 8 | |
| 9 | SYNOPSIS |
| 10 | -------- |
| 11 | [synopsis] |
| 12 | git worktree add [-f] [--detach] [--checkout] [--lock [--reason <string>]] |
| 13 | [--orphan] [(-b | -B) <new-branch>] <path> [<commit-ish>] |
| 14 | git worktree list [-v | --porcelain [-z]] |
| 15 | git worktree lock [--reason <string>] <worktree> |
| 16 | git worktree move <worktree> <new-path> |
| 17 | git worktree prune [-n] [-v] [--expire <expire>] |
| 18 | git worktree remove [-f] <worktree> |
| 19 | git worktree repair [<path>...] |
| 20 | git worktree unlock <worktree> |
| 21 | |
| 22 | DESCRIPTION |
| 23 | ----------- |
| 24 | |
| 25 | Manage multiple working trees attached to the same repository. |
| 26 | |
| 27 | A git repository can support multiple working trees, allowing you to check |
| 28 | out more than one branch at a time. With `git worktree add` a new working |
| 29 | tree is associated with the repository, along with additional metadata |
| 30 | that differentiates that working tree from others in the same repository. |
| 31 | The working tree, along with this metadata, is called a "worktree". |
| 32 | |
| 33 | This new worktree is called a "linked worktree" as opposed to the "main |
| 34 | worktree" prepared by linkgit:git-init[1] or linkgit:git-clone[1]. |
| 35 | A repository has one main worktree (if it's not a bare repository) and |
| 36 | zero or more linked worktrees. When you are done with a linked worktree, |
| 37 | remove it with `git worktree remove`. |
| 38 | |
| 39 | In its simplest form, `git worktree add <path>` automatically creates a |
| 40 | new branch whose name is the final component of _<path>_, which is |
| 41 | convenient if you plan to work on a new topic. For instance, `git |
| 42 | worktree add ../hotfix` creates new branch `hotfix` and checks it out at |
| 43 | path `../hotfix`. To instead work on an existing branch in a new worktree, |
| 44 | use `git worktree add <path> <branch>`. On the other hand, if you just |
| 45 | plan to make some experimental changes or do testing without disturbing |
| 46 | existing development, it is often convenient to create a 'throwaway' |
| 47 | worktree not associated with any branch. For instance, |
| 48 | `git worktree add -d <path>` creates a new worktree with a detached `HEAD` |
| 49 | at the same commit as the current branch. |
| 50 | |
| 51 | If a working tree is deleted without using `git worktree remove`, then |
| 52 | its associated administrative files, which reside in the repository |
| 53 | (see "DETAILS" below), will eventually be removed automatically (see |
| 54 | `gc.worktreePruneExpire` in linkgit:git-config[1]), or you can run |
| 55 | `git worktree prune` in the main or any linked worktree to clean up any |
| 56 | stale administrative files. |
| 57 | |
| 58 | If the working tree for a linked worktree is stored on a portable device |
| 59 | or network share which is not always mounted, you can prevent its |
| 60 | administrative files from being pruned by issuing the `git worktree lock` |
| 61 | command, optionally specifying `--reason` to explain why the worktree is |
| 62 | locked. |
| 63 | |
| 64 | COMMANDS |
| 65 | -------- |
| 66 | `add <path> [<commit-ish>]`:: |
| 67 | |
| 68 | Create a worktree at _<path>_ and checkout _<commit-ish>_ into it. The new worktree |
| 69 | is linked to the current repository, sharing everything except per-worktree |
| 70 | files such as `HEAD`, `index`, etc. As a convenience, _<commit-ish>_ may |
| 71 | be a bare "`-`", which is synonymous with `@{-1}`. |
| 72 | + |
| 73 | If _<commit-ish>_ is a branch name (call it _<branch>_) and is not found, |
| 74 | and neither `-b` nor `-B` nor `--detach` are used, but there does |
| 75 | exist a tracking branch in exactly one remote (call it _<remote>_) |
| 76 | with a matching name, treat as equivalent to: |
| 77 | + |
| 78 | ------------ |
| 79 | $ git worktree add --track -b <branch> <path> <remote>/<branch> |
| 80 | ------------ |
| 81 | + |
| 82 | If the branch exists in multiple remotes and one of them is named by |
| 83 | the `checkout.defaultRemote` configuration variable, we'll use that |
| 84 | one for the purposes of disambiguation, even if the _<branch>_ isn't |
| 85 | unique across all remotes. Set it to |
| 86 | e.g. `checkout.defaultRemote=origin` to always checkout remote |
| 87 | branches from there if _<branch>_ is ambiguous but exists on the |
| 88 | `origin` remote. See also `checkout.defaultRemote` in |
| 89 | linkgit:git-config[1]. |
| 90 | + |
| 91 | If _<commit-ish>_ is omitted and neither `-b` nor `-B` nor `--detach` used, |
| 92 | then, as a convenience, the new worktree is associated with a branch (call |
| 93 | it _<branch>_) named after `$(basename <path>)`. If _<branch>_ doesn't |
| 94 | exist, a new branch based on `HEAD` is automatically created as if |
| 95 | `-b <branch>` was given. If _<branch>_ does exist, it will be checked out |
| 96 | in the new worktree, if it's not checked out anywhere else, otherwise the |
| 97 | command will refuse to create the worktree (unless `--force` is used). |
| 98 | + |
| 99 | If _<commit-ish>_ is omitted, neither `--detach`, or `--orphan` is |
| 100 | used, and there are no valid local branches (or remote branches if |
| 101 | `--guess-remote` is specified) then, as a convenience, the new worktree is |
| 102 | associated with a new unborn branch named _<branch>_ (after |
| 103 | `$(basename <path>)` if neither `-b` or `-B` is used) as if `--orphan` was |
| 104 | passed to the command. In the event the repository has a remote and |
| 105 | `--guess-remote` is used, but no remote or local branches exist, then the |
| 106 | command fails with a warning reminding the user to fetch from their remote |
| 107 | first (or override by using `-f`/`--force`). |
| 108 | |
| 109 | `list`:: |
| 110 | |
| 111 | List details of each worktree. The main worktree is listed first, |
| 112 | followed by each of the linked worktrees. The output details include |
| 113 | whether the worktree is bare, the revision currently checked out, the |
| 114 | branch currently checked out (or "detached HEAD" if none), "locked" if |
| 115 | the worktree is locked, "prunable" if the worktree can be pruned by the |
| 116 | `prune` command. |
| 117 | |
| 118 | `lock`:: |
| 119 | |
| 120 | If a worktree is on a portable device or network share which is not always |
| 121 | mounted, lock it to prevent its administrative files from being pruned |
| 122 | automatically. This also prevents it from being moved or deleted. |
| 123 | Optionally, specify a reason for the lock with `--reason`. |
| 124 | |
| 125 | `move`:: |
| 126 | |
| 127 | Move a worktree to a new location. Note that the main worktree or linked |
| 128 | worktrees containing submodules cannot be moved with this command. (The |
| 129 | `git worktree repair` command, however, can reestablish the connection |
| 130 | with linked worktrees if you move the main worktree manually.) |
| 131 | |
| 132 | `prune`:: |
| 133 | |
| 134 | Remove worktree information in `$GIT_DIR/worktrees` for worktrees |
| 135 | whose working trees are missing. Useful after manually removing |
| 136 | a working tree that is no longer needed (but use "git worktree |
| 137 | remove" next time you want to do so). Also, if you _moved_ a |
| 138 | working tree elsewhere causing the worktree information to become |
| 139 | dangling, see "git worktree repair" to reconnect the worktree to |
| 140 | the new working tree location. |
| 141 | |
| 142 | `remove`:: |
| 143 | |
| 144 | Remove a worktree. Only clean worktrees (no untracked files and no |
| 145 | modification in tracked files) can be removed. Unclean worktrees or ones |
| 146 | with submodules can be removed with `--force`. The main worktree cannot be |
| 147 | removed. |
| 148 | |
| 149 | `repair [<path>...]`:: |
| 150 | |
| 151 | Repair worktree administrative files, if possible, if they have become |
| 152 | corrupted or outdated due to external factors. |
| 153 | + |
| 154 | For instance, if the main worktree (or bare repository) is moved, linked |
| 155 | worktrees will be unable to locate it. Running `repair` in the main |
| 156 | worktree will reestablish the connection from linked worktrees back to the |
| 157 | main worktree. |
| 158 | + |
| 159 | Similarly, if the working tree for a linked worktree is moved without |
| 160 | using `git worktree move`, the main worktree (or bare repository) will be |
| 161 | unable to locate it. Running `repair` within the recently-moved worktree |
| 162 | will reestablish the connection. If multiple linked worktrees are moved, |
| 163 | running `repair` from any worktree with each tree's new _<path>_ as an |
| 164 | argument, will reestablish the connection to all the specified paths. |
| 165 | + |
| 166 | If both the main worktree and linked worktrees have been moved or copied manually, |
| 167 | then running `repair` in the main worktree and specifying the new _<path>_ |
| 168 | of each linked worktree will reestablish all connections in both |
| 169 | directions. |
| 170 | |
| 171 | `unlock`:: |
| 172 | |
| 173 | Unlock a worktree, allowing it to be pruned, moved or deleted. |
| 174 | |
| 175 | OPTIONS |
| 176 | ------- |
| 177 | |
| 178 | `-f`:: |
| 179 | `--force`:: |
| 180 | By default, `add` refuses to create a new worktree when |
| 181 | _<commit-ish>_ is a branch name and is already checked out by |
| 182 | another worktree, or if _<path>_ is already assigned to some |
| 183 | worktree but is missing (for instance, if _<path>_ was deleted |
| 184 | manually). This option overrides these safeguards. To add a missing but |
| 185 | locked worktree path, specify `--force` twice. |
| 186 | + |
| 187 | `move` refuses to move a locked worktree unless `--force` is specified |
| 188 | twice. If the destination is already assigned to some other worktree but is |
| 189 | missing (for instance, if _<new-path>_ was deleted manually), then `--force` |
| 190 | allows the move to proceed; use `--force` twice if the destination is locked. |
| 191 | + |
| 192 | `remove` refuses to remove an unclean worktree unless `--force` is used. |
| 193 | To remove a locked worktree, specify `--force` twice. |
| 194 | |
| 195 | `-b <new-branch>`:: |
| 196 | `-B <new-branch>`:: |
| 197 | With `add`, create a new branch named _<new-branch>_ starting at |
| 198 | _<commit-ish>_, and check out _<new-branch>_ into the new worktree. |
| 199 | If _<commit-ish>_ is omitted, it defaults to `HEAD`. |
| 200 | By default, `-b` refuses to create a new branch if it already |
| 201 | exists. `-B` overrides this safeguard, resetting _<new-branch>_ to |
| 202 | _<commit-ish>_. |
| 203 | |
| 204 | `-d`:: |
| 205 | `--detach`:: |
| 206 | With `add`, detach `HEAD` in the new worktree. See "DETACHED HEAD" |
| 207 | in linkgit:git-checkout[1]. |
| 208 | |
| 209 | `--checkout`:: |
| 210 | `--no-checkout`:: |
| 211 | By default, `add` checks out _<commit-ish>_, however, `--no-checkout` can |
| 212 | be used to suppress checkout in order to make customizations, |
| 213 | such as configuring sparse-checkout. See "Sparse checkout" |
| 214 | in linkgit:git-read-tree[1]. |
| 215 | |
| 216 | `--guess-remote`:: |
| 217 | `--no-guess-remote`:: |
| 218 | With `worktree add <path>`, without _<commit-ish>_, instead |
| 219 | of creating a new branch from `HEAD`, if there exists a tracking |
| 220 | branch in exactly one remote matching the basename of _<path>_, |
| 221 | base the new branch on the remote-tracking branch, and mark |
| 222 | the remote-tracking branch as "upstream" from the new branch. |
| 223 | + |
| 224 | This can also be set up as the default behaviour by using the |
| 225 | `worktree.guessRemote` config option. |
| 226 | |
| 227 | `--relative-paths`:: |
| 228 | `--no-relative-paths`:: |
| 229 | Link worktrees using relative paths or absolute paths (default). |
| 230 | Overrides the `worktree.useRelativePaths` config option, see |
| 231 | linkgit:git-config[1]. |
| 232 | + |
| 233 | With `repair`, the linking files will be updated if there's an absolute/relative |
| 234 | mismatch, even if the links are correct. |
| 235 | |
| 236 | `--track`:: |
| 237 | `--no-track`:: |
| 238 | When creating a new branch, if _<commit-ish>_ is a branch, |
| 239 | mark it as "upstream" from the new branch. This is the |
| 240 | default if _<commit-ish>_ is a remote-tracking branch. See |
| 241 | `--track` in linkgit:git-branch[1] for details. |
| 242 | |
| 243 | `--lock`:: |
| 244 | Keep the worktree locked after creation. This is the |
| 245 | equivalent of `git worktree lock` after `git worktree add`, |
| 246 | but without a race condition. |
| 247 | |
| 248 | `-n`:: |
| 249 | `--dry-run`:: |
| 250 | With `prune`, do not remove anything; just report what it would |
| 251 | remove. |
| 252 | |
| 253 | `--orphan`:: |
| 254 | With `add`, make the new worktree and index empty, associating |
| 255 | the worktree with a new unborn branch named _<new-branch>_. |
| 256 | |
| 257 | `--porcelain`:: |
| 258 | With `list`, output in an easy-to-parse format for scripts. |
| 259 | This format will remain stable across Git versions and regardless of user |
| 260 | configuration. It is recommended to combine this with `-z`. |
| 261 | See below for details. |
| 262 | |
| 263 | `-z`:: |
| 264 | Terminate each line with a _NUL_ rather than a newline when |
| 265 | `--porcelain` is specified with `list`. This makes it possible |
| 266 | to parse the output when a worktree path contains a newline |
| 267 | character. |
| 268 | |
| 269 | `-q`:: |
| 270 | `--quiet`:: |
| 271 | With `add`, suppress feedback messages. |
| 272 | |
| 273 | `-v`:: |
| 274 | `--verbose`:: |
| 275 | With `prune`, report all removals. |
| 276 | + |
| 277 | With `list`, output additional information about worktrees (see below). |
| 278 | |
| 279 | `--expire <time>`:: |
| 280 | With `prune`, only prune missing worktrees if older than _<time>_. |
| 281 | + |
| 282 | With `list`, annotate missing worktrees as prunable if they are older than |
| 283 | _<time>_. |
| 284 | |
| 285 | `--reason <string>`:: |
| 286 | With `lock` or with `add --lock`, an explanation why the worktree |
| 287 | is locked. |
| 288 | |
| 289 | _<worktree>_:: |
| 290 | Worktrees can be identified by path, either relative or absolute. |
| 291 | + |
| 292 | If the last path components in the worktree's path is unique among |
| 293 | worktrees, it can be used to identify a worktree. For example if you only |
| 294 | have two worktrees, at `/abc/def/ghi` and `/abc/def/ggg`, then `ghi` or |
| 295 | `def/ghi` is enough to point to the former worktree. |
| 296 | |
| 297 | REFS |
| 298 | ---- |
| 299 | When using multiple worktrees, some refs are shared between all worktrees, |
| 300 | but others are specific to an individual worktree. One example is `HEAD`, |
| 301 | which is different for each worktree. This section is about the sharing |
| 302 | rules and how to access refs of one worktree from another. |
| 303 | |
| 304 | In general, all pseudo refs are per-worktree and all refs starting with |
| 305 | `refs/` are shared. Pseudo refs are ones like `HEAD` which are directly |
| 306 | under `$GIT_DIR` instead of inside `$GIT_DIR/refs`. There are exceptions, |
| 307 | however: refs inside `refs/bisect`, `refs/worktree` and `refs/rewritten` are |
| 308 | not shared. |
| 309 | |
| 310 | Refs that are per-worktree can still be accessed from another worktree via |
| 311 | two special paths, `main-worktree` and `worktrees`. The former gives |
| 312 | access to per-worktree refs of the main worktree, while the latter to all |
| 313 | linked worktrees. |
| 314 | |
| 315 | For example, `main-worktree/HEAD` or `main-worktree/refs/bisect/good` |
| 316 | resolve to the same value as the main worktree's `HEAD` and |
| 317 | `refs/bisect/good` respectively. Similarly, `worktrees/foo/HEAD` or |
| 318 | `worktrees/bar/refs/bisect/bad` are the same as |
| 319 | `$GIT_COMMON_DIR/worktrees/foo/HEAD` and |
| 320 | `$GIT_COMMON_DIR/worktrees/bar/refs/bisect/bad`. |
| 321 | |
| 322 | To access refs, it's best not to look inside `$GIT_DIR` directly. Instead |
| 323 | use commands such as linkgit:git-rev-parse[1] or linkgit:git-update-ref[1] |
| 324 | which will handle refs correctly. |
| 325 | |
| 326 | CONFIGURATION FILE |
| 327 | ------------------ |
| 328 | By default, the repository `config` file is shared across all worktrees. |
| 329 | If the config variables `core.bare` or `core.worktree` are present in the |
| 330 | common config file and `extensions.worktreeConfig` is disabled, then they |
| 331 | will be applied to the main worktree only. |
| 332 | |
| 333 | In order to have worktree-specific configuration, you can turn on the |
| 334 | `worktreeConfig` extension, e.g.: |
| 335 | |
| 336 | ------------ |
| 337 | $ git config extensions.worktreeConfig true |
| 338 | ------------ |
| 339 | |
| 340 | In this mode, specific configuration stays in the path pointed by `git |
| 341 | rev-parse --git-path config.worktree`. You can add or update |
| 342 | configuration in this file with `git config --worktree`. Older Git |
| 343 | versions will refuse to access repositories with this extension. |
| 344 | |
| 345 | Note that in this file, the exception for `core.bare` and `core.worktree` |
| 346 | is gone. If they exist in `$GIT_DIR/config`, you must move |
| 347 | them to the `config.worktree` of the main worktree. You may also take this |
| 348 | opportunity to review and move other configuration that you do not want to |
| 349 | share to all worktrees: |
| 350 | |
| 351 | - `core.worktree` should never be shared. |
| 352 | |
| 353 | - `core.bare` should not be shared if the value is `core.bare=true`. |
| 354 | |
| 355 | - `core.sparseCheckout` should not be shared, unless you are sure you |
| 356 | always use sparse checkout for all worktrees. |
| 357 | |
| 358 | See the documentation of `extensions.worktreeConfig` in |
| 359 | linkgit:git-config[1] for more details. |
| 360 | |
| 361 | DETAILS |
| 362 | ------- |
| 363 | Each linked worktree has a private sub-directory in the repository's |
| 364 | `$GIT_DIR/worktrees` directory. The private sub-directory's name is usually |
| 365 | the base name of the linked worktree's path, possibly appended with a |
| 366 | number to make it unique. For example, when `$GIT_DIR=/path/main/.git` the |
| 367 | command `git worktree add /path/other/test-next next` creates the linked |
| 368 | worktree in `/path/other/test-next` and also creates a |
| 369 | `$GIT_DIR/worktrees/test-next` directory (or `$GIT_DIR/worktrees/test-next1` |
| 370 | if `test-next` is already taken). |
| 371 | |
| 372 | Within a linked worktree, `$GIT_DIR` is set to point to this private |
| 373 | directory (e.g. `/path/main/.git/worktrees/test-next` in the example) and |
| 374 | `$GIT_COMMON_DIR` is set to point back to the main worktree's `$GIT_DIR` |
| 375 | (e.g. `/path/main/.git`). These settings are made in a `.git` file located at |
| 376 | the top directory of the linked worktree. |
| 377 | |
| 378 | Path resolution via `git rev-parse --git-path` uses either |
| 379 | `$GIT_DIR` or `$GIT_COMMON_DIR` depending on the path. For example, in the |
| 380 | linked worktree `git rev-parse --git-path HEAD` returns |
| 381 | `/path/main/.git/worktrees/test-next/HEAD` (not |
| 382 | `/path/other/test-next/.git/HEAD` or `/path/main/.git/HEAD`) while `git |
| 383 | rev-parse --git-path refs/heads/master` uses |
| 384 | `$GIT_COMMON_DIR` and returns `/path/main/.git/refs/heads/master`, |
| 385 | since refs are shared across all worktrees, except `refs/bisect`, |
| 386 | `refs/worktree` and `refs/rewritten`. |
| 387 | |
| 388 | See linkgit:gitrepository-layout[5] for more information. The rule of |
| 389 | thumb is do not make any assumption about whether a path belongs to |
| 390 | `$GIT_DIR` or `$GIT_COMMON_DIR` when you need to directly access something |
| 391 | inside `$GIT_DIR`. Use `git rev-parse --git-path` to get the final path. |
| 392 | |
| 393 | If you manually move a linked worktree, you need to update the `gitdir` file |
| 394 | in the entry's directory. For example, if a linked worktree is moved |
| 395 | to `/newpath/test-next` and its `.git` file points to |
| 396 | `/path/main/.git/worktrees/test-next`, then update |
| 397 | `/path/main/.git/worktrees/test-next/gitdir` to reference `/newpath/test-next` |
| 398 | instead. Better yet, run `git worktree repair` to reestablish the connection |
| 399 | automatically. |
| 400 | |
| 401 | To prevent a `$GIT_DIR/worktrees` entry from being pruned (which |
| 402 | can be useful in some situations, such as when the |
| 403 | entry's worktree is stored on a portable device), use the |
| 404 | `git worktree lock` command, which adds a file named |
| 405 | `locked` to the entry's directory. The file contains the reason in |
| 406 | plain text. For example, if a linked worktree's `.git` file points |
| 407 | to `/path/main/.git/worktrees/test-next` then a file named |
| 408 | `/path/main/.git/worktrees/test-next/locked` will prevent the |
| 409 | `test-next` entry from being pruned. See |
| 410 | linkgit:gitrepository-layout[5] for details. |
| 411 | |
| 412 | When `extensions.worktreeConfig` is enabled, the config file |
| 413 | `.git/worktrees/<id>/config.worktree` is read after `.git/config` is. |
| 414 | |
| 415 | LIST OUTPUT FORMAT |
| 416 | ------------------ |
| 417 | The `worktree list` command has two output formats. The default format shows the |
| 418 | details on a single line with columns. For example: |
| 419 | |
| 420 | ------------ |
| 421 | $ git worktree list |
| 422 | /path/to/bare-source (bare) |
| 423 | /path/to/linked-worktree abcd1234 [master] |
| 424 | /path/to/other-linked-worktree 1234abc (detached HEAD) |
| 425 | ------------ |
| 426 | |
| 427 | The command also shows annotations for each worktree, according to its state. |
| 428 | These annotations are: |
| 429 | |
| 430 | * `locked`, if the worktree is locked. |
| 431 | * `prunable`, if the worktree can be pruned via `git worktree prune`. |
| 432 | |
| 433 | ------------ |
| 434 | $ git worktree list |
| 435 | /path/to/linked-worktree abcd1234 [master] |
| 436 | /path/to/locked-worktree acbd5678 (brancha) locked |
| 437 | /path/to/prunable-worktree 5678abc (detached HEAD) prunable |
| 438 | ------------ |
| 439 | |
| 440 | For these annotations, a reason might also be available and this can be |
| 441 | seen using the verbose mode. The annotation is then moved to the next line |
| 442 | indented followed by the additional information. |
| 443 | |
| 444 | ------------ |
| 445 | $ git worktree list --verbose |
| 446 | /path/to/linked-worktree abcd1234 [master] |
| 447 | /path/to/locked-worktree-no-reason abcd5678 (detached HEAD) locked |
| 448 | /path/to/locked-worktree-with-reason 1234abcd (brancha) |
| 449 | locked: worktree path is mounted on a portable device |
| 450 | /path/to/prunable-worktree 5678abc1 (detached HEAD) |
| 451 | prunable: gitdir file points to non-existent location |
| 452 | ------------ |
| 453 | |
| 454 | Note that the annotation is moved to the next line if the additional |
| 455 | information is available, otherwise it stays on the same line as the |
| 456 | worktree itself. |
| 457 | |
| 458 | Porcelain Format |
| 459 | ~~~~~~~~~~~~~~~~ |
| 460 | The porcelain format has a line per attribute. If `-z` is given then the lines |
| 461 | are terminated with NUL rather than a newline. Attributes are listed with a |
| 462 | label and value separated by a single space. Boolean attributes (like `bare` |
| 463 | and `detached`) are listed as a label only, and are present only |
| 464 | if the value is true. Some attributes (like `locked`) can be listed as a label |
| 465 | only or with a value depending upon whether a reason is available. The first |
| 466 | attribute of a worktree is always `worktree`, an empty line indicates the |
| 467 | end of the record. For example: |
| 468 | |
| 469 | ------------ |
| 470 | $ git worktree list --porcelain |
| 471 | worktree /path/to/bare-source |
| 472 | bare |
| 473 | |
| 474 | worktree /path/to/linked-worktree |
| 475 | HEAD abcd1234abcd1234abcd1234abcd1234abcd1234 |
| 476 | branch refs/heads/master |
| 477 | |
| 478 | worktree /path/to/other-linked-worktree |
| 479 | HEAD 1234abc1234abc1234abc1234abc1234abc1234a |
| 480 | detached |
| 481 | |
| 482 | worktree /path/to/linked-worktree-locked-no-reason |
| 483 | HEAD 5678abc5678abc5678abc5678abc5678abc5678c |
| 484 | branch refs/heads/locked-no-reason |
| 485 | locked |
| 486 | |
| 487 | worktree /path/to/linked-worktree-locked-with-reason |
| 488 | HEAD 3456def3456def3456def3456def3456def3456b |
| 489 | branch refs/heads/locked-with-reason |
| 490 | locked reason why is locked |
| 491 | |
| 492 | worktree /path/to/linked-worktree-prunable |
| 493 | HEAD 1233def1234def1234def1234def1234def1234b |
| 494 | detached |
| 495 | prunable gitdir file points to non-existent location |
| 496 | |
| 497 | ------------ |
| 498 | |
| 499 | Unless `-z` is used any "unusual" characters in the lock reason such as newlines |
| 500 | are escaped and the entire reason is quoted as explained for the |
| 501 | configuration variable `core.quotePath` (see linkgit:git-config[1]). |
| 502 | For Example: |
| 503 | |
| 504 | ------------ |
| 505 | $ git worktree list --porcelain |
| 506 | ... |
| 507 | locked "reason\nwhy is locked" |
| 508 | ... |
| 509 | ------------ |
| 510 | |
| 511 | EXAMPLES |
| 512 | -------- |
| 513 | You are in the middle of a refactoring session and your boss comes in and |
| 514 | demands that you fix something immediately. You might typically use |
| 515 | linkgit:git-stash[1] to store your changes away temporarily, however, your |
| 516 | working tree is in such a state of disarray (with new, moved, and removed |
| 517 | files, and other bits and pieces strewn around) that you don't want to risk |
| 518 | disturbing any of it. Instead, you create a temporary linked worktree to |
| 519 | make the emergency fix, remove it when done, and then resume your earlier |
| 520 | refactoring session. |
| 521 | |
| 522 | ------------ |
| 523 | $ git worktree add -b emergency-fix ../temp master |
| 524 | $ pushd ../temp |
| 525 | # ... hack hack hack ... |
| 526 | $ git commit -a -m 'emergency fix for boss' |
| 527 | $ popd |
| 528 | $ git worktree remove ../temp |
| 529 | ------------ |
| 530 | |
| 531 | CONFIGURATION |
| 532 | ------------- |
| 533 | |
| 534 | include::includes/cmd-config-section-all.adoc[] |
| 535 | |
| 536 | include::config/worktree.adoc[] |
| 537 | |
| 538 | BUGS |
| 539 | ---- |
| 540 | Multiple checkout in general is still experimental, and the support |
| 541 | for submodules is incomplete. It is NOT recommended to make multiple |
| 542 | checkouts of a superproject. |
| 543 | |
| 544 | GIT |
| 545 | --- |
| 546 | Part of the linkgit:git[1] suite |