本文详解 godep 在多包单仓库项目中的正确使用方式，强调必须在仓库根目录执行 godep save ./...，避免将本地子包误 vendored 到 _workspace，从而消除代码重复、同步滞后和维护混乱等问题。
本文详解 godep 在多包单仓库项目中的正确使用方式，强调必须在仓库根目录执行 godep save ./...，避免将本地子包误 vendored 到 _workspace，从而消除代码重复、同步滞后和维护混乱等问题。
在 Go 1.5 引入 vendor 机制之前，Godep 是主流的依赖管理工具。然而，许多开发者在面对单仓库多模块结构（如 myplace/myprojectRepo/{someCmd, somePackage}）时，常因调用位置不当导致 Godep 行为异常——最典型的问题是：在 someCmd/ 目录下执行 godep save，结果 somePackage/ 的源码也被复制进 Godeps/_workspace/src/，造成本地包被“双重存在”，既违背语义（本地包本应直连引用），又引发开发流断裂（修改 somePackage 后需反复 godep save 才能生效）。
根本原因在于：Godep 的依赖解析基于当前工作目录的导入路径上下文，且默认不向上追溯 GOPATH 或仓库根目录。当你在 someCmd/ 下运行 godep save，它会解析 main.go 中所有 import 语句，并将所有非当前目录子路径的依赖（包括同级的 somePackage）视为外部依赖，进而 vendoring 进 _workspace —— 即使二者物理上属于同一 Git 仓库。
✅ 正确做法：始终在仓库根目录（即 myplace/myprojectRepo/）执行 Godep 命令：
cd src/myplace/myprojectRepo/ godep save ./...
该命令中 ./... 表示“递归扫描当前目录下所有 Go 包”，Godep 将：
- 正确识别 someCmd 和 somePackage 属于同一代码基线（共享相同 import path 前缀，如 myplace/myprojectRepo/...）；
- 仅 vendor 第三方依赖（如 github.com/sirupsen/logrus），跳过所有以本仓库路径开头的本地包；
- 生成统一、精简的 Godeps/Godeps.json，其中 "ImportPath" 字段清晰区分内外部依赖。
? 补充关键实践：
- 团队协作前提：所有成员必须从仓库根目录执行 godep restore，确保 _workspace 环境一致；
- CI/CD 集成：构建脚本应显式 cd $REPO_ROOT && godep restore && go build ./someCmd；
- 迁移建议：若项目已存在错误 vendoring，先删除 Godeps/_workspace 和 Godeps/Godeps.json，再按上述规范重建。
⚠️ 注意事项：
- 不要将 Godeps/_workspace 提交至 Git（.gitignore 中应包含 Godeps/_workspace）；
- godep save 不会自动更新 go.mod（Godep 与 Go Modules 不兼容），若计划迁移到 Go 1.11+，建议逐步转向 go mod；
- 本地包路径必须符合 Go 导入规范（如 import "myplace/myprojectRepo/somePackage"），否则 Godep 无法正确识别其归属。
总结而言，Godep 的“本地包误 vendoring”并非工具缺陷，而是路径作用域误用所致。坚持单仓单 Godeps、根目录操作、./... 全量扫描三原则，即可实现干净、可复现、易协作的依赖管理。
