如果您的实验出错，您可以自由地进行尝试，同时安全地拥有存储库的新链接克隆。Git在某种程度上被设计为实验性的。如果您知道您的工作将被安全跟踪并处于安全状态，以防万一出现可怕的错误，您就不会害怕尝试新想法。然而，创新的部分代价是你可能会在这个过程中搞砸。文件被重命名、移动、删除、更改、粉碎；引入新文件；您不打算跟踪的临时文件占用了您的工作目录等位置。简而言之，您的工作区变成了纸牌屋，在“快到了！”之间摇摇欲坠地保持平衡。和“哦，不，我做了什么？”那么当你需要在下午将仓库恢复到已知状态以便完成一些真正的工作时，你会怎么做呢？马上想到gitbranch和gitstash两个经典命令，但这两个都不是为处理未跟踪文件而设计的，文件路径更改和其他主要转换可能会造成混淆，它们只是可以将Work隐藏起来以备后用。这个需求的答案是Git工作树。什么是Git工作树？Git工作树是Git存储库的链接副本，允许您同时检出多个分支。工作树位于与主工作副本不同的路径上，它可以处于不同的状态和不同的分支上。在Git中创建一个新的工作树的好处是，您可以进行与当前任务无关的更改，提交更改，然后在以后合并它们，而不会打扰当前的工作环境。直接从git-worktree手册中找到一个经典示例：当您正在为一个项目开发一个令人兴奋的新功能时，您的项目经理告诉您有一个紧急修复需要处理。问题在于您的工作存储库（您的“工作树”）一团糟，因为您正在开发一项主要的新功能。您不想在当前sprint中“偷偷”修复，也不想暂存更改并为修复创建新分支。相反，您决定创建一个新的工作树，以便在那里进行修复：$gitbranch|tee*devtrunk$gitworktreeadd-bhotfix~/code/hotfixtrunkPreparing../hotfix(identifierhotfix)HEAD现在位于62a2dafcommit在你的代码目录中，你现在有一个名为hotfix的新目录，这是一个Git工作树连接到您的主项目存储库，其HEAD位于名为trunk的分支上。现在您可以将此工作树视为您的主要工作区。您可以将目录切换到其中，执行修补程序、提交并最终删除工作树：$cd~/code/hotfix$sed-i's/teh/the/'hello.txt$gitcommit--all--message'urgenthotfix'完成紧急修复后，您可以返回到之前的任务。您可以控制何时将修补程序集成到主项目中。例如，您可以将更改直接从其工作树推送到项目的远程存储库：$gitpushoriginHEAD$cd~/code/myproject或者您可以将工作树存档为TAR或ZIP文件：$cd~/code/myproject$gitarchive--formattar--outputhotfix.tarmaster或者您可以从单独的工作树中获取本地更改：$gitworktreelist/home/seth/code/myproject15fca84[dev]/home/seth/code/修补程序09e585d[master]从那里，您可以使用最适合您和您的团队的任何策略合并您的更改。列出活动的工作树您可以使用gitworktreelist命令获取工作树列表，并查看每个工作树检查了哪些分支：$gitworktreelist/home/seth/code/myproject15fca84[dev]/home/seth/code/修补程序09e585d[master]您可以在任何工作树中使用此功能。工作树总是连接的（除非你手动移动它们，破坏Git定位工作树的能力，从而切断连接）。移动工作树Git会跟踪项目.git目录中工作树的位置和状态：$cat~/code/myproject/.git/worktrees/hotfix/gitdir/home/seth/code/hotfix/.git如果你需要重新定位一个工作树，你必须使用gitworktreemove；否则，当Git尝试更新工作树的状态时，它将失败：$mkdir~/Temp$gitworktreemovehotfix~/Temp$gitworktreelist/home/seth/code/myproject15fca84[dev]/home/seth/Temp/hotfix09e585d[master]删除worktree完成工作后，可以使用remove子命令将其删除：$gitworktreeremovehotfix$gitworktreelist/home/seth/code/myproject15fca84[dev]要确保您的.git目录是干净的，请在删除工作树后使用prune子命令：$gitworktreeremoveprune何时使用工作树与许多选项一样，无论是标签还是书签或自动备份，都取决于您跟踪您生成的数据，否则它会变得势不可挡。不要过于频繁地使用工作树，否则您最终会得到20个存储库副本，每个副本的状态都略有不同。我发现最好创建一个工作树，执行需要它的任务，提交工作，然后删除树。保持简单和专注。重要的是，工作树在管理Git存储库的方式上提供了更大的灵活性。在需要时使用它们，永远不要争先恐后地保存您的工作状态以再次查看另一个分支上的内容。
