仅使用Git链接工作区而非主工作区会面临哪些问题与限制？

如果你计划完全依赖git worktree add创建的链接工作区开展工作，仅保留主工作区（存放.git目录的原始仓库）但从不使用它，可能会遇到以下几类问题和限制：

• 核心Git元数据依赖风险
  所有链接工作区共享主工作区的.git目录，一旦主工作区被误删除、移动或损坏，所有关联的链接工作区都会立即失去Git功能，无法执行任何Git命令。即使你从不操作主工作区，也必须确保它的目录结构和.git目录始终完整。

• 部分Git命令的行为差异
  一些Git命令在链接工作区执行时会有隐含限制：

  • 执行git worktree remove删除当前链接工作区时，若主工作区的HEAD指向的分支被链接工作区占用，可能会触发冲突提示；
  • git gc、git prune这类维护命令，在链接工作区执行时会作用于整个仓库（包括主工作区），如果主工作区存在未清理的临时文件或无效引用，可能影响链接工作区的性能；
  • 在链接工作区创建新分支时，主工作区的HEAD不会自动同步，长期下来主工作区的分支状态会和你实际使用的链接工作区完全脱节，后续临时使用主工作区时会出现分支混乱。

• 开发工具的支持瑕疵
  尽管IntelliJ IDEA的新版本（2022.3及以后）已经修复了链接工作区的核心支持问题，但仍存在边缘场景的小问题：

  • 部分第三方插件（如特定代码质量检查、Git提交模板插件）可能未适配链接工作区，导致功能失效；
  • VS Code的部分Git扩展、SourceTree等GUI工具对链接工作区的支持仍不完善，可能出现分支识别错误、状态刷新延迟、无法正确执行stash操作等问题；
  • 终端中的Git自动补全脚本，偶尔会无法正确识别链接工作区的分支名称。

• 钩子与自定义配置的限制
  Git钩子（如pre-commit、post-merge）存放在主工作区的.git/hooks目录下，所有链接工作区共享同一套钩子。如果需要为不同链接工作区设置差异化的钩子逻辑，无法直接实现，只能通过修改钩子脚本增加分支判断等复杂逻辑。

• 备份与迁移的额外成本
  备份或迁移仓库时，不能只复制链接工作区的目录，必须同时包含主工作区的.git目录和对应工作区文件（即使你从不使用主工作区的文件）。仅备份链接工作区的话，恢复后无法正常使用Git功能。

• 长期维护的隐性负担
  主工作区的工作目录会保留最初创建时的文件状态，长期不清理可能积累大量无用文件；同时，主工作区的HEAD分支若长期不更新，执行跨工作区分支操作时可能出现意想不到的冲突。

内容的提问来源于stack exchange，提问作者vaughan