1

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
4

2 回答 2

1

lock子命令 ( )的git worktree lock存在专门用于防止主存储库在添加的工作树打开时（例如，并非始终安装的拇指驱动器）认为工作树“已消失”。这里的用例是：

  • 插入U盘，挂载文件系统
  • 在拇指驱动器上添加工作树，使用一段时间
  • 锁定工作树并移除（卸载和断开连接）拇指驱动器
  • 稍后，重新插入 U 盘，解锁工作树，继续工作

这一切都在一台具有一个主存储库的机器上。目前尚不清楚这是您的意思，还是您的意思是：

  • 插入拇指驱动器并挂载文件系统
  • 在拇指驱动器上添加工作树，使用，锁定，卸载/删除驱动器
  • 在具有相同存储库的单独克隆的不同计算机（我们称之为 machine-X）上插入拇指驱动器origin
  • 在那里使用拇指驱动器工作树（在移除拇指驱动器时适当锁定/解锁，以便管理文件不会消失）

这可以工作，但有一些问题。首先，没有正式的方式告诉 Git：“我从未为此存储库创建的这个工作树现在突然存在，请添加它”。但是，如果您曾经git worktree add在拇指驱动器工作树所在的位置创建工作树，然后将拇指驱动器安装在该区域上（可能在 Git 不知道的情况下删除工作树本身之后），那将起作用，在一两个约束下。

具体来说，当您在添加的工作树中时：

  1. 此工作树的HEAD和索引文件实际上位于主存储库中。
  2. 每次git add将文件复制到索引时，不仅主存储库中的索引本身会更新，底层 Git 对象也会进入主存储库。

因此，您还必须带入这些文件的内容——每个工作树HEAD和索引，以及底层的 Git 对象文件——如果你从它们之后的内容中更改它们的话git worktree add。如果没有，git worktree add你在机器 X 上做一次，在你交换拇指驱动器工作树之前进行设置就足够了。

（请注意，如果您确实rungit add或 modify HEAD，则底层存储库对象在 2.15.0 之前的 Git 版本中是不安全的，该版本已修复。本质上，主工作树可以在默认修剪到期后 gc 它们，通常为 14 天。短此警告的版本相当于“不要让添加的工作树使用超过两周”，尽管这有点过度概括。稍微相关：重命名可能在添加的工作树中的分支在 2.15 之前的 Git 版本中是错误的.0.)

于 2018-11-28T22:39:00.843 回答
0

完成一些工作（添加提交）后分离工作树，目录不应该被删除

是的，自 2019 年第一季度和 Git 2.23 以来这是可能的，现在使用 Git 2.29（2020 年第四季度）和git worktree它本身（不需要git checkout --detach.

在 Git 2.29（2020 年第四季度）中，“ git worktree add” （man）了解到“ -d”是“ --detach”选项的同义词，可以在不位于分支上的情况下创建新的工作树。

请参阅Eric Sunshine ( )的commit dccadad、commit c670aa4、commit 07351d9（2020 年 9 月 6 日） 。（由Junio C Hamano 合并 -- --在提交 45f462b中，2020 年 9 月 18 日）sunshineco
gitster

worktree: 教add识别-d为简写--detach

签字人：Eric Sunshine

像( man )和( man )一样，( man )可以签出一个分支或设置一个分离的 HEAD。git switchgit checkoutgit worktree add

但是，与其他命令不同，( man )不能理解为 的简写，这可能会使习惯用于此目的的用户感到困惑。git worktree add-d--detach-d

通过教授add识别-dfor来解决这个缺点--detach，从而使其与其他命令保持一致。

更普遍：

git-worktree.txt：讨论基于分支与一次性工作树

签字人：Eric Sunshine

默认情况下，( man )创建与特定分支关联的新工作树（如果未在命令行上明确指定，则可能已自动创建）。git worktree add

创建与任何分支无关的一次性工作树也很方便，这在进行实验性更改或进行测试时会很方便。

但是，后一种用例对于新手来说可能并不明显，因为工作树的高级描述只讨论了“一次检查多个分支”。
因此，增强描述以讨论这两个用例。

强调基于分支和一次性工作树之间区别的第二个目标是帮助新手理解最简单的形式（man）会自动创建一个新分支。git worktree add <path>

在描述的早期说明这一点，可以帮助新手避免在没有意识到他们正在这样做的情况下创建分支，然后想知道为什么（man）显示用户没有故意创建的分支。git branch --list

git worktree现在在其手册页中包含：

以最简单的形式，git worktree add <path>自动创建一个名为 的最后一个组件的新分支，<path>如果您打算研究一个新主题，这很方便。

例如，git worktree add ../hotfix创建新分支hotfix并在 path 处签出../hotfix。

要改为在新工作树中的现有分支上工作，请使用git worktree add <path> <branch>.

另一方面，如果您只是打算在不影响现有开发的情况下进行一些实验性更改或进行测试，那么创建一个不与任何分支关联的“一次性”工作树通常很方便。

例如，在与当前分支相同的提交处git worktree add -d <path>创建一个分离的新工作树。HEAD

于 2020-09-19T13:38:43.943 回答