@@ -25,45 +25,49 @@ Manage multiple working trees attached to the same repository.
25
25
26
26
A git repository can support multiple working trees, allowing you to check
27
27
out more than one branch at a time. With `git worktree add` a new working
28
- tree is associated with the repository. This new working tree is called a
29
- "linked working tree" as opposed to the "main working tree" prepared by
30
- linkgit:git-init[1] or linkgit:git-clone[1].
31
- A repository has one main working tree (if it's not a
32
- bare repository) and zero or more linked working trees. When you are done
33
- with a linked working tree, remove it with `git worktree remove`.
28
+ tree is associated with the repository, along with additional metadata
29
+ that differentiates that working tree from others in the same repository.
30
+ The working tree, along with this metadata, is called a "worktree".
31
+
32
+ This new worktree is called a "linked worktree" as opposed to the "main
33
+ worktree" prepared by linkgit:git-init[1] or linkgit:git-clone[1].
34
+ A repository has one main worktree (if it's not a bare repository) and
35
+ zero or more linked worktrees. When you are done with a linked worktree,
36
+ remove it with `git worktree remove`.
34
37
35
38
In its simplest form, `git worktree add <path>` automatically creates a
36
39
new branch whose name is the final component of `<path>`, which is
37
40
convenient if you plan to work on a new topic. For instance, `git
38
41
worktree add ../hotfix` creates new branch `hotfix` and checks it out at
39
- path `../hotfix`. To instead work on an existing branch in a new working
40
- tree, use `git worktree add <path> <branch>`. On the other hand, if you
41
- just plan to make some experimental changes or do testing without
42
- disturbing existing development, it is often convenient to create a
43
- 'throwaway' working tree not associated with any branch. For instance,
44
- `git worktree add -d <path>` creates a new working tree with a detached
45
- `HEAD` at the same commit as the current branch.
42
+ path `../hotfix`. To instead work on an existing branch in a new worktree,
43
+ use `git worktree add <path> <branch>`. On the other hand, if you just
44
+ plan to make some experimental changes or do testing without disturbing
45
+ existing development, it is often convenient to create a 'throwaway'
46
+ worktree not associated with any branch. For instance,
47
+ `git worktree add -d <path>` creates a new worktree with a detached `HEAD`
48
+ at the same commit as the current branch.
46
49
47
50
If a working tree is deleted without using `git worktree remove`, then
48
51
its associated administrative files, which reside in the repository
49
52
(see "DETAILS" below), will eventually be removed automatically (see
50
53
`gc.worktreePruneExpire` in linkgit:git-config[1]), or you can run
51
- `git worktree prune` in the main or any linked working tree to
52
- clean up any stale administrative files.
54
+ `git worktree prune` in the main or any linked worktree to clean up any
55
+ stale administrative files.
53
56
54
- If a linked working tree is stored on a portable device or network share
55
- which is not always mounted, you can prevent its administrative files from
56
- being pruned by issuing the `git worktree lock` command, optionally
57
- specifying `--reason` to explain why the working tree is locked.
57
+ If the working tree for a linked worktree is stored on a portable device
58
+ or network share which is not always mounted, you can prevent its
59
+ administrative files from being pruned by issuing the `git worktree lock`
60
+ command, optionally specifying `--reason` to explain why the worktree is
61
+ locked.
58
62
59
63
COMMANDS
60
64
--------
61
65
add <path> [<commit-ish>]::
62
66
63
- Create `<path>` and checkout `<commit-ish>` into it. The new working directory
64
- is linked to the current repository, sharing everything except working
65
- directory specific files such as `HEAD`, `index`, etc. As a convenience,
66
- `<commit-ish>` may be a bare "`-`", which is synonymous with `@{-1}`.
67
+ Create a worktree at `<path>` and checkout `<commit-ish>` into it. The new worktree
68
+ is linked to the current repository, sharing everything except per-worktree
69
+ files such as `HEAD`, `index`, etc. As a convenience, `<commit-ish>` may
70
+ be a bare "`-`", which is synonymous with `@{-1}`.
67
71
+
68
72
If `<commit-ish>` is a branch name (call it `<branch>`) and is not found,
69
73
and neither `-b` nor `-B` nor `--detach` are used, but there does
0 commit comments