本文详解 Godep 在多包单仓库项目中的正确使用方式，指出在子目录执行 godep save 会导致本地包被错误 vendoring 的根本原因，并提供从项目根目录统一管理依赖的标准实践。
本文详解 godep 在多包单仓库项目中的正确使用方式，指出在子目录执行 `godep save` 会导致本地包被错误 vendoring 的根本原因，并提供从项目根目录统一管理依赖的标准实践。
Godep 是 Go 1.5 之前广泛使用的依赖管理工具，其核心机制是通过 _workspace 目录“vendor”所有非当前工作区路径下的导入包。关键在于：Godep 判断是否 vendor 某个包，依据的是该包的导入路径是否属于当前 GOPATH 下的本地代码——而它不会向上追溯项目根目录或识别逻辑上的“同一仓库”。
在您描述的目录结构中：
src/
└── myplace/
└── myprojectRepo/
├── someCmd/
│ └── main.go // import "myplace/myprojectRepo/somePackage"
└── somePackage/
└── package.go
若在 someCmd/ 目录下运行 godep save，Godep 会将 main.go 中所有 import 语句解析为绝对导入路径（如 "myplace/myprojectRepo/somePackage"）。由于当前工作目录是 someCmd/，Godep 无法识别 somePackage/ 是同一 Git 仓库内的 sibling 目录，而是将其视为一个需 vendored 的“外部”本地包——于是将其完整复制进 Godeps/_workspace/src/myplace/myprojectRepo/somePackage/，造成重复和同步难题。
✅ 正确做法：始终从项目根目录（即 myprojectRepo/）执行 Godep 命令：
cd src/myplace/myprojectRepo godep save ./...
- ./... 表示递归扫描当前目录及其所有子目录下的 Go 包；
- Godep 将自动识别 someCmd 和 somePackage 同属本项目，仅 vendor 真正的第三方依赖（如 github.com/sirupsen/logrus），而跳过 myplace/myprojectRepo/ 下的所有包；
- 生成的 Godeps/Godeps.json 将只记录外部依赖，Godeps/_workspace 中不再出现冗余的本地包副本。
⚠️ 重要注意事项：
- 所有协作者必须在克隆仓库后，在 myprojectRepo/ 目录下执行 godep restore，而非子目录；
- 确保 GOPATH 设置合理（推荐 GOPATH=$(pwd)/../../.. 或使用 go mod vendor 迁移替代）；
- godep save 默认不保存测试依赖（*_test.go 中的 import），如需包含，请加 -t 标志：godep save -t ./...；
- 鉴于 Godep 已停止维护，生产项目强烈建议迁移到 Go Modules（go mod init && go mod tidy），它原生支持本地包引用且无需 vendoring 同仓库代码。
总结：Godep 的行为由工作目录与导入路径的相对关系决定，而非 Git 仓库边界。统一在项目根目录操作，是避免本地包误 vendoring、保障依赖一致性的唯一可靠方式。
