Git不会让你两次检出同一个分支，因为如果你这样做了，然后转到两个工作树中的一个并进行一次新的提交，那么当你回到另一个工作树时，你就会陷入痛苦的境地。
如果你已经删除了另一个工作树，只需运行git worktree prune让Git意识到这一点。如果你没有删除其他工作树，不要检查两次：不好玩。

如果您在手册git-checkout(1)中搜索“工作树”，您会发现

git checkout --ignore-other-worktrees <branch>

字符串
但是你可能只是想做以下的事情，这样当你移动（提交）一个工作树中的分支时，另一个工作树的HEAD不会被移动。

git checkout --detach <branch>

型

如何在不删除.git/worktrees目录的情况下绕过这个问题？
使用Git 2.17+（Q2 2018）会更轻松，因为“git worktree“已经学习了”move“和”remove“子命令。
参见commit 7f19def（2018年3月4日），由Eric Sunshine ( sunshineco )提供。
请参见Nguyễn Thái Ngọc Duy ( pclouds )的commit ee6763a、commit cc73385、commit 78d986b、commit c64a8d2、commit 9f792bb、commit 9c620fc（2018年2月12日）和commit 4ddddc1（2018年1月24日）。
（2018年3月14日，由Junio C Hamano -- gitster --合并至commit bd0f794）
在您的情况下，您可以将现有的工作树 * 移动 * 到您现在想要的位置（当您尝试为同一分支创建新的工作树时）。

worktree move：我的天啊！新命令

使用此命令可以重新定位链接的工作树。
主工作树（尚）无法移动。
还有：

worktree move：我的天啊！拒绝移动包含子模块的工作树

子模块包含带有相对路径的.git文件。
在worktree move之后，这些文件需要更新，否则它们可能无处指向。
这是一个绷带补丁，以确保“worktree move“不会意外破坏人们的工作树。
当.git文件更新代码就位时，可以删除此validate_no_submodules()。
注意：在Git 2.21（Q1 2019）之前，当涉及到子模块时，“git worktree remove“和“git worktree move“拒绝工作。
This has been loosened to ignore uninitialized submodules的函数。

因为你不能在工作树和原始仓库中 checkout 两次。在 checkout 工作树之前，将原始仓库 checkout 到其他地方怎么样？

git -C </other/location> checkout <branch>~1
git -C <worktree> checkout <branch>

字符串

只需转到所需分支的worktree目录，它就会自动为您提供checkout。
在我的例子中，我有两个长时间运行的worktree，这意味着master旁边有两个相关的分支。

$git branch
master  # base stuff here
version-silver # some normal features
version-gold # some better features

字符串
有一个存储库，但我有3个单独的文件夹旁边的每个分支以上。并在master中进行常见更改。然后将其与其他两个版本合并。
每个版本的具体更改也会放在相应的文件夹中，每个项目上的工作都是隔离的，IDE不会混淆。
希望能帮上忙。

如果你真的想绕过这个检查，你可以直接修改相应HEAD文件中的引用，或者重新创建一个同名的分支，例如：第一个月
正如其他人所说，你需要知道你在做什么;分支是所有工作树的公共分支，更改一个工作树中的一个分支将立即影响其他工作树的状态。

在我的例子中，当分支 * 没有 * 在其他工作树中 checkout 时发生了这种情况，所以我真的很困惑！然而，我在.git/worktrees中寻找分支名称，发现该工作树位于该分支的一个重基中间，而我已经忘记了。在git rebase --abort和git checkout工作树中的某个其他分支之后，问题得到了解决。

请注意，如果$pwd中有链接，也会发生这种情况。git在检查之前可能应该在$pwd上readlink -f。
编辑：或者这确实可能是因为我错过了调用git worktree prune。现在起作用了