Git worktree与submodule：按仓库历史选择
这些代码块对应不同情况，不是一个完整脚本。请选择适合仓库的情况，并替换分支名、路径和VERIFIED_COMMIT。中止命令只适用于对应的正在进行的操作，不要执行两种备选方案。
简短答案
需要同一仓库的另一检出来并行工作或审查分支时用worktree。父仓库需要把另一个仓库的特定提交记录为依赖时用submodule。前者增加共享历史的工作目录，后者引入独立版本历史并由父仓库记录选择。
| 选择 | Worktree | Submodule |
|---|---|---|
| 历史 | 同一仓库，共享对象和多数引用 | 独立子仓库，父仓库记录其提交 |
| 文件 | 独立HEAD、索引和工作目录 | 子仓库检出与父HEAD/索引固定版本可能不同 |
| 版本 | 同一仓库的分支或提交 | 选择的子提交，不只由.gitmodules决定 |
| 更新 | 审查并整合选定分支 | 检出记录的固定提交；--remote是另一种选择 |
| 限制 | 通常每个分支只能有一个检出；不是权限隔离 | 多个worktree中的支持不完整；子仓库工作独立 |
示例与前提
首先判断谁管理历史。两个代理尝试同一应用的替代修复，通常需要独立分支和工作区。有自己发布流程的库可能需要固定依赖。两者都不是权限sandbox；文件系统和代理权限仍需分别管理。
修改前检查状态
linked worktree有自己的HEAD、索引和文件，同时共享对象及多数引用。你可以保留当前编辑并审查另一分支。Git通常阻止同一分支被两个worktree同时检出。共享对象不会把未暂存编辑自动复制到另一个目录。
git status --short
git branch --show-current
git worktree list保留引用或独立检出
检查状态，在../topic-review创建review/worktree。用git -C检查该检出和提交后，才整合选择的结果。目录分开能减少任务混淆，却不能保证更改兼容。整合后运行相关检查，避免两个工具同时修改同一检出。
git worktree add -b review/worktree ../topic-review HEAD
git -C ../topic-review status --short
git -C ../topic-review branch --show-current第一种操作
submodule是父路径内的独立仓库。父已提交树用通常模式160000的gitlink记录子提交。父索引可以暂存另一提交，子HEAD也可能与两者不同。.gitmodules说明路径与URL；版本选择由记录的提交决定。
有意选择另一种结果
对于deps/library，分别看submodule status、父HEAD的gitlink、索引gitlink和子HEAD。父pull可改变固定版本而不移动子检出。普通submodule update采用记录的选择；--remote有意跟随远程选择，是另一项版本更新决策，不是为了消除脏状态。
git submodule status -- deps/library
git ls-tree HEAD -- deps/library
git ls-files --stage -- deps/library
git -C deps/library rev-parse HEAD
git --no-optional-locks -C deps/library status --short限制与例外
Git文档说明多个worktree中的submodule支持不完整。添加--recursive不让任意组合变成受支持的隔离环境。检查限制及真实检出、更新流程；需要独立状态时可考虑单独clone。这不是自动组合两者的万能教程。
冲突与清理
移除worktree前检查未提交文件和分支，再用worktree remove而非盲目删除目录。保留需要的分支或已审查合并。改依赖版本前，按子仓库流程提交并发布更改，让其他clone可以获取，然后在父仓库记录所选提交。
git -C ../topic-review status --short
git worktree remove ../topic-review
git worktree list验证结果
worktree要验证分支、状态和整合结果。submodule要比较三个状态，并确认预期使用者能获取子对象。父状态干净不代表所有子工作区干净。两者都不永久备份未提交文件；验证要根据历史关系进行。
git worktree list
git submodule status -- deps/library常见问题
worktree用于不替换当前检出而处理另一分支。submodule用于在父仓库固定独立版本的依赖。单独更新规则会增加协调成本。包管理器、vendoring、subtree或独立clone都是可选方案，应按版本归属与交付需求决定，没有万能胜者。
在FluxGit中审查操作
使用FluxGit的可视历史与差异视图审查操作及相关提交。保留本例中的分支、共享历史和本地文件检查。下载页面列出当前提供的版本及平台。