Is there a way to detach and attach git worktrees?

Question

Is there a way to detach and attach git worktrees? Basically, I'd like to have the following workflow:

1. Create a worktree
2. Detach work tree after doing some work (adding commits), the directory should not get deleted
3. checkout worktree branch in my main checkout
4. do some push/linting/pushing to company server
5. reattach worktree, and continue working on existing directory if necessary

To explain my reasoning behind my workflow... I have a bunch of settings which are tied into the path of the of the main checkout repository... this includes linting/pre-commit checks and some other workflows (the setup is complicated, and I am unaware of the details)... what I'd ideally like to do is the following switch back and forth from the git worktree to the main checkout location of the repo.... similar to how you would switch between branches.

e.g. I do the following

1. create worktree branch A in dir A
2. do some edits
3. "unlock" worktree A
4. checkout branch A branch in main checkout directory
5. do linting/pre-check operation (these do not edit any file in the branch)
6. checkout master branch in main checkout directory
7. go back to editing worktree A in dir A

Answer 1

Detach work tree after doing some work (adding commits), the directory should not get deleted

Yes, this is possible since Q1 2019 and Git 2.23, now even clearer with with Git 2.29 (Q4 2020) and git worktree itself (no need for git checkout --detach).

With Git 2.29 (Q4 2020), "git worktree add"^(man) learns that the "-d" is a synonym to "--detach" option to create a new worktree without being on a branch.

---

As noted by Qwerty in the comments, it works with a local branch (myBranch), not a remotee tracking branch (origin/myBranch)

git worktree add <path> origin/myBranch creates a detached HEAD from the source branch, even without the new --detach option.

---

See commit dccadad, commit c670aa4, commit 07351d9 (06 Sep 2020) by Eric Sunshine (sunshineco).
^{(Merged by Junio C Hamano -- gitster -- in commit 45f462b, 18 Sep 2020)}

worktree: teach add to recognize -d as shorthand for --detach

^{Signed-off-by: Eric Sunshine}

Like git switch^(man) and git checkout^(man), git worktree add^(man) can check out a branch or set up a detached HEAD.

However, unlike those other commands, git worktree add^(man) does not understand -d as shorthand for --detach, which may confound users accustomed to using -d for this purpose.

Address this shortcoming by teaching add to recognize -d for --detach, thus bringing it in line with the other commands.

More generally:

git-worktree.txt: discuss branch-based vs. throwaway worktrees

^{Signed-off-by: Eric Sunshine}

By default, git worktree add^(man) creates a new worktree associated with a particular branch (which may have been created automatically if not specified explicitly on the command-line).

It is also convenient to create throwaway worktrees not associated with any branch, which can be handy when making experimental changes or doing testing.

However, the latter use-case may not be obvious to newcomers since the high-level description of worktrees talks only about checking out "more than one branch at a time".
Therefore, enhance the description to to discuss both use-cases.

A secondary goal of highlighting the distinction between branch-based and throwaway worktrees is to help newcomers understand that the simplest form git worktree add <path>^(man) automatically creates a new branch.

Stating this early in the description, may help newcomers avoid creating branches without realizing they are doing so, and later wondering why git branch --list^(man) shows branches the user did not intentionally create.

git worktree now includes in its man page:

In its simplest form, git worktree add <path> automatically creates a new branch whose name is the final component of <path>, which is convenient if you plan to work on a new topic.

For instance, git worktree add ../hotfix creates new branch hotfix and checks it out at path ../hotfix.

To instead work on an existing branch in a new working tree, use git worktree add <path> <branch>.

On the other hand, if you just plan to make some experimental changes or do testing without disturbing existing development, it is often convenient to create a 'throwaway' working tree not associated with any branch.

For instance, git worktree add -d <path> creates a new working tree with a detached HEAD at the same commit as the current branch.

Answer 2

The lock subcommand (git worktree lock) exists specifically to keep the main repository from considering the worktree "gone" if the added work-tree is on, e.g., a thumb drive that is not always mounted. The use case here is:

• insert thumb drive, mount file system
• add work-tree on thumb drive, use it for a while
• lock work-tree and remove (unmount and disconnect) thumb drive
• later, re-insert thumb drive, unlock work tree, continue working

which is all on one machine with one main repository. It's not clear if this is what you meant, or if you meant:

• insert thumb drive and mount file system
• add work-tree on thumb drive, use, lock, unmount/remove drive
• insert thumb drive on different computer (let's call it machine-X) that has a separate clone of the same origin repo
• use thumb-drive work-tree there (with lock/unlock as appropriate while thumb drive is removed, so that the admin files don't vanish)

This could work, but has some issues. First, there is no formal way to tell Git: "this work-tree that I never created for this repository suddenly exists now, please add it". However, if you used git worktree add to create a work-tree in the place that the thumb drive work-tree will be, and then mount the thumb drive over that area (perhaps after removing the work-tree itself without Git knowing), that will work, under a constraint or two.

Specifically, when you're in an added work-tree:

1. The HEAD and index files for this work-tree actually live inside the main repository.
2. Every time you git add a file to copy it to the index, not only is the index itself in the main repository updated, the underlying Git object goes into the main repository as well.

Hence you'd have to also bring over the contents of those files—the per-worktree HEAD and index, plus the underlying Git object files—if you ever change them from the contents they have right after git worktree add. If not, the git worktree add you do on machine-X, once, to set things up before you swap in the thumb drive work-tree, will suffice.

(Note that if you do run git add or modify HEAD, the underlying repository objects are not safe in Git versions through 2.15.0, where this was fixed. Essentially, the main worktree can gc them after the default prune expiration, typically 14 days. The short version of this warning amounts to "don't keep added worktrees in use for more than two weeks", though that's a bit of an over-generalization. Slightly related: renaming branches that might be in added worktrees is buggy in Git versions predating 2.15.0.)