在自有项目中引入TensorFlow Object Detection API及tensorflow/models的最佳实践

1. Git 子模块（Git Submodule） #

• 好处：
  • 项目仓库不会臃肿，仅追踪tensorflow/models的特定commit引用，无需将整个仓库内容纳入自有项目
  • 能精准锁定依赖版本，可随时切换到适配自身TensorFlow版本的分支或commit
  • 避免重复存储大型仓库内容，有效控制项目仓库体积
• 麻烦点：
  • 团队协作时需额外操作：克隆项目后要执行git submodule init和git submodule update，新人上手需注意该步骤
  • 子模块的更新、分支切换需单独操作，流程比普通Git操作繁琐
• 适用场景：需要严格控制tensorflow/models版本，团队成员熟悉Git子模块操作，且希望保持项目仓库轻量化的情况

2. Git 子树（Git Subtree） #

• 好处：
  • 将tensorflow/models的内容直接合并到自有仓库，协作时无需额外操作，克隆项目即可直接使用
  • 可自由修改tensorflow/models代码（比如自定义API适配自身需求），修改内容能直接提交到自有仓库
  • 无需记忆子模块的特殊命令，操作逻辑和普通Git流程一致
• 麻烦点：
  • 会增加项目仓库体积，因为包含了tensorflow/models的全部内容
  • 后续同步上游tensorflow/models的更新时，操作相对复杂，容易出现冲突
• 适用场景：需要对tensorflow/models做自定义修改，或团队成员不熟悉子模块、希望简化协作流程的情况

3. 直接克隆后纳入自有仓库 #

• 好处：
  • 完全自主控制，可随意修改代码，无需处理子模块/子树的特殊命令
  • 本地开发无需额外步骤，直接即可使用
• 麻烦点：
  • 项目仓库体积会显著增大，推送、拉取速度变慢
  • 无法便捷同步上游tensorflow/models的更新，只能手动复制替换，容易丢失自身修改内容
  • 不符合Git依赖管理的最佳实践，冗余内容过多
• 适用场景：仅用于临时测试，或项目无需长期维护、也不需要同步上游更新的极端情况

总结建议 #

如果你的项目需要长期维护，且无需修改tensorflow/models的核心代码，优先选择Git子模块，既能精准控制版本又能保持仓库轻量化；如果需要自定义修改API，且希望简化团队协作流程，选择Git子树；直接克隆纳入仓库仅适合临时场景，不推荐长期使用。

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