理解“双重Git”困境
在go语言的早期版本中，项目依赖通常通过go get命令获取并放置在$gopath/src目录下。当一个go项目本身使用git进行版本控制时，如果其依赖也是一个git仓库（例如从github获取），就会出现所谓的“双重git”困境。具体表现为：
- go get的行为： 当go get下载一个Go包时，如果该包的源是一个Git仓库，go get会将其作为一个完整的Git仓库下载到$GOPATH/src下的相应路径中，包括其内部的.git目录。
- 父Git仓库的行为： 当主项目（父仓库）尝试通过git add命令添加文件时，Git会默认忽略任何嵌套的.git目录。这意味着，即使依赖库的代码文件物理上存在于你的项目目录结构中，父Git仓库也不会追踪这些文件的变更，而是将其视为一个独立的Git子仓库，或者更常见的情况是，根本不将其内容纳入版本控制。
这种行为导致的问题是，父项目无法直接管理和追踪其依赖库的精确版本状态，使得项目构建的可复现性面临挑战，尤其是在没有网络连接或依赖源发生变化时。如果开发者为项目设置了自定义的$GOPATH，使得依赖直接下载到项目本身的目录层级内，这个问题会更加突出。
手动集成依赖：移除.git目录
面对上述困境，一种直接但略显粗暴的解决方案是手动移除go get下载的依赖库内部的.git目录。
原理： 通过删除依赖库内部的.git目录，该依赖库就不再被父Git仓库视为一个独立的Git仓库，而仅仅是一个普通的文件夹及其包含的文件。这样，父Git仓库就可以像追踪普通源代码文件一样，追踪这些依赖文件的变更，并将它们一并提交到父仓库中。这本质上是一种手动的“vendoring”（内嵌依赖）方式。
操作步骤：
-
执行 go get 获取依赖： 首先，像往常一样使用go get命令下载所需的第三方依赖。
# 假设你的项目结构如下，且GOPATH设置使得依赖下载到项目内部 # /path/to/your/project/ # ├── .git/ # └── src/ # └── github.com/yourname/yourproject/ # 你的项目根目录 # └── main.go # # 假设你的GOPATH被设置为 /path/to/your/project/src # 或者你在项目根目录执行 go get，且Go版本低于1.11（无模块模式） # 在你的项目根目录或适当位置执行 go get cd /path/to/your/project/src/github.com/yourname/yourproject/ go get github.com/someuser/somelib
-
导航至依赖库目录： 找到go get下载的依赖库所在的具体路径。
# 假设依赖下载到了 /path/to/your/project/src/github.com/someuser/somelib cd /path/to/your/project/src/github.com/someuser/somelib
-
移除 .git 目录： 使用rm -rf命令删除该目录下的.git文件夹。
rm -rf .git
-
在父仓库中添加并提交： 返回你的项目根目录，执行git add .和git commit，将依赖库的代码作为普通文件添加到你的主项目中。
cd /path/to/your/project/ git add . git commit -m "Add github.com/someuser/somelib dependency by stripping .git"
注意事项：
- 更新依赖： 如果需要更新某个依赖，你需要再次执行go get -u（这可能会重新下载并创建.git目录），然后重复上述移除.git目录的步骤。
- 丢失Git历史： 这种方法会使父仓库丢失对依赖库自身Git历史的追踪能力。父仓库只记录了依赖库在某个时间点的快照。
- 手动操作： 这是一个手动过程，对于大量依赖或频繁更新的项目来说，效率较低且容易出错。
现代Go项目依赖管理：Go Modules
对于现代Go项目，官方推荐且更健壮的依赖管理方案是使用Go Modules。Go Modules从Go 1.11版本引入，并在Go 1.16及更高版本中成为默认模式，彻底解决了GOPATH模式下的诸多依赖管理问题，包括“双重Git”困境。
核心概念：
- go.mod文件： 项目根目录下的go.mod文件声明了项目所需的依赖及其版本。
- go.sum文件： 记录了每个依赖模块的加密校验和，用于确保依赖的完整性和安全性。
- 模块缓存： 依赖不再直接下载到项目内部的$GOPATH/src，而是下载到全局的模块缓存目录（通常是$GOPATH/pkg/mod），并在需要时引用。
工作原理：
-
初始化模块： 在项目根目录执行go mod init
来初始化一个Go模块。 # 假设你的项目根目录是 /path/to/your/project/ cd /path/to/your/project/ go mod init github.com/yourname/yourproject
这会生成一个go.mod文件。
-
添加或更新依赖：
- 当你导入并使用一个新包时，go build、go run或go test会自动检测并下载该依赖。
- 你可以使用go get
@ 来获取特定版本的依赖。 - go mod tidy命令会清理不再使用的依赖，并添加新发现的依赖，同时更新go.sum文件。
# 获取特定版本依赖 go get github.com/someuser/somelib@v1.2.3
清理和同步所有依赖
go mod tidy
内嵌依赖 (Vendoring) 与 Git：
默认情况下，Go Modules不会将依赖代码直接放入你的项目仓库。但如果你有特殊需求，例如为了确保在没有网络连接的情况下也能构建项目，或者为了满足公司内部的安全审计要求，你可以使用go mod vendor命令将所有依赖复制到项目根目录的vendor文件夹中。
-
生成 vendor 目录：
cd /path/to/your/project/ go mod vendor
这会在项目根目录创建一个vendor文件夹，其中包含了所有项目依赖的源代码。这些依赖文件将不再包含.git目录。
-
将 vendor 目录添加到Git并提交：
git add vendor go.mod go.sum git commit -m "Add vendor dependencies and module files"
现在，vendor目录及其内容被父Git仓库完全追踪，实现了依赖的内嵌管理。在构建时，Go编译器会优先查找vendor目录中的依赖。
Go Modules的优势：
- 版本精确控制： go.mod文件精确定义了每个依赖的版本，确保构建的可复现性。
- 隔离性： 依赖存储在全局缓存，避免了不同项目间的依赖冲突。
- 官方支持： 作为官方推荐方案，拥有良好的生态支持和持续维护。
- 自动化： 大部分依赖管理操作（下载、更新、清理）都通过go mod命令自动化完成。
不推荐的方案：Git Submodule
git submodule是Git本身提供的管理子项目的功能。理论上，你可以将每个Go依赖作为一个git submodule添加到你的项目中。然而，对于Go项目的依赖管理来说，这通常不是一个推荐的方案。
原因：
- 复杂性高： Go项目通常有大量依赖，将每个依赖都作为子模块管理会极大地增加项目的复杂性，包括初始化、更新和切换分支等操作。
- 不符合Go生态： Go语言的依赖管理（无论是早期的GOPATH还是现在的Go Modules）都旨在提供更轻量级、更自动化的解决方案，git submodule的粒度过粗，不符合Go的哲学。
- Go Modules的优越性： Go Modules提供了更专业、更强大的依赖管理能力，远超git submodule在Go依赖场景下的适用性。
总结与最佳实践
在Go语言项目中处理go get下载的依赖与主Git仓库的协同问题时，我们有以下最佳实践：
- 拥抱Go Modules： 对于所有新项目和可迁移的旧项目，强烈建议使用Go Modules进行依赖管理。这是Go语言官方推荐且最健壮的方案。
- 使用 go mod vendor 进行内嵌依赖： 如果你的项目环境（如CI/CD、离线构建、公司政策）要求将依赖代码纳入版本控制，那么请使用go mod vendor命令。这会生成一个vendor目录，你可以将其添加到Git中，从而确保项目在任何环境下都能构建成功，并且所有依赖都受到主仓库的版本控制。
- 避免手动移除 .git： 尽管手动移除.git目录是一种可行的方案，但它效率低下，缺乏自动化，且会丢失依赖的Git历史信息。除非在非常特殊的、无法使用Go Modules的场景下，否则不建议采用此方法。
- 避免使用 git submodule： git submodule不适用于Go项目的依赖管理，因为它会引入不必要的复杂性，且Go Modules提供了更优的解决方案。
通过采用Go Modules及其相关功能，开发者可以有效地管理Go项目的依赖，解决“双重Git”困境，确保项目构建的可复现性、稳定性和安全性。
