本文介绍在使用 govendor 管理 Go 项目依赖时，如何安全、规范地将某个依赖（如 gopkg.in/h2non/bimg.v1）切换至其上游仓库（如 github.com/h2non/bimg）的最新 master 分支或任意指定 commit，避免手动替换 vendor 文件。
本文介绍在使用 govendor 管理 go 项目依赖时，如何安全、规范地将某个依赖（如 gopkg.in/h2non/bimg.v1）切换至其上游仓库（如 github.com/h2non/bimg）的最新 master 分支或任意指定 commit，避免手动替换 vendor 文件。
在 Go 项目中，govendor 是早期广泛使用的依赖管理工具（早于 Go Modules）。当项目已通过 govendor 锁定某个依赖的特定版本（如 gopkg.in/h2non/bimg.v1 对应 v1.0.7 的某次 commit），但你需要升级到上游 github.com/h2non/bimg 的 master 分支（或某次特定 commit）时，不能仅修改 vendor/vendor.json 中的 revision 字段并手动替换文件——这会破坏校验一致性，且 govendor sync 或后续操作可能覆盖更改。
✅ 正确做法是利用 govendor 原生命令完成「移除旧引用 → 从源仓库拉取新版本 → 更新 vendor.json 和 vendor 目录」的完整流程：
1. 移除旧依赖引用
首先清除当前 vendor.json 中对 gopkg.in/h2non/bimg.v1 的声明，并同步清理 vendor/ 下对应路径：
govendor remove gopkg.in/h2non/bimg.v1
该命令会自动：
- 从
vendor/vendor.json中删除对应 package 条目； - 删除
vendor/gopkg.in/h2non/bimg.v1/目录（如有）。
2. 从真实源仓库拉取目标版本
注意：gopkg.in/h2non/bimg.v1 是 github.com/h2non/bimg 的语义化别名（v1 分支或 tag），而 master 分支实际托管在 GitHub 原始仓库。因此需直接以 github.com/h2non/bimg 为导入路径拉取：
# 拉取 master 分支最新 HEAD govendor fetch github.com/h2non/bimg # 或拉取指定 commit（例如：a1b2c3d） govendor fetch github.com/h2non/bimg@a1b2c3d # 或拉取特定分支（如 v1.1.x） govendor fetch github.com/h2non/bimg@v1.1.0
govendor fetch 会：
- 自动解析
go.mod（若存在）或Godeps/Godeps.json（若存在），否则按git clone+git checkout行为获取代码； - 将代码复制到
vendor/github.com/h2non/bimg/； - 在
vendor/vendor.json中新增条目，记录path、revision、revisionTime和checksumSHA1，确保可重现性。
⚠️ 注意：
fetch后的导入路径变为github.com/h2non/bimg，因此你需同步更新项目中所有import "gopkg.in/h2non/bimg.v1"为import "github.com/h2non/bimg"，否则编译失败。
3. （可选）仅更新 vendor.json 而不下载代码
若你已手动准备好代码（如通过 git clone 放入 vendor/），仅希望生成元数据条目，可用：
govendor add github.com/h2non/bimg
但该方式不校验一致性，不推荐用于生产环境；优先使用 fetch 保证完整性。
验证与提交
执行完成后，建议验证：
- 运行
govendor list +local确认新包已列出； - 编译项目（
go build ./...）确保无 import 冲突； - 检查
vendor/vendor.json中新条目是否含正确revision和checksumSHA1； - 提交
vendor/vendor.json和vendor/github.com/h2non/bimg/（因所有依赖已提交）。
? 小结：govendor 的设计哲学是“声明式 + 可重现”，一切变更应通过其 CLI 驱动，而非手动编辑文件或目录。remove + fetch 是切换源仓库/分支/commit 的标准范式，兼顾安全性、可追溯性与团队协作一致性。
