理解“双重Git”问题及其根源
在使用git进行项目版本控制时，如果项目目录内部包含另一个git仓库（即存在嵌套的.git目录），主项目的git默认不会跟踪这个嵌套仓库的任何文件。它会将整个嵌套仓库视为一个独立的文件，其内容变化不会被主项目git详细记录，执行git status时通常会显示为gitlink类型或直接忽略其内部变更。
Go语言的go get命令在获取第三方依赖时，通常会从远程Git仓库（如GitHub）下载完整的源代码，包括其内部的.git目录。如果开发者配置了一个自定义的GOPATH，并将其设置在主项目目录结构内部（例如，GOPATH=/path/to/myproject/src/go/），那么所有通过go get下载的依赖都会被放置在myproject/src/go/src/github.com/somename/someproject这样的路径下。此时，主项目Git就会遇到上述的“双重Git”问题，无法直接将这些依赖的源代码纳入自身的版本控制。
解决方案：剥离依赖仓库的Git元数据
为了解决“双重Git”问题，并允许主项目Git直接管理所有依赖的源代码，一种直接的方法是剥离这些通过go get下载的依赖仓库中的Git元数据。这意味着删除依赖目录中的.git和.gitignore文件，从而将这些依赖视为普通的源代码文件，而非独立的Git仓库。
操作步骤：
-
执行go get获取依赖： 确保所有需要的第三方依赖都已通过go get下载到你的GOPATH中。
go get github.com/somename/someproject
- 定位GOPATH下的依赖目录： 假设你的GOPATH被设置为/path/to/myproject/src/go。
-
剥离Git元数据： 使用find命令递归地查找并删除所有依赖目录中的.git目录和.gitignore文件。
# 假设你的GOPATH是 /path/to/myproject/src/go # 确保在执行此命令前，你已切换到GOPATH的根目录或其上级目录 # 或者直接指定GOPATH/src作为查找路径 find "/path/to/myproject/src/go/src" -type d -name ".git" -exec rm -rf {} + find "/path/to/myproject/src/go/src" -type f -name ".gitignore" -exec rm -f {} +上述命令会遍历GOPATH/src下的所有目录，并删除其中找到的.git目录及其内容，以及.gitignore文件。
-
将依赖文件添加到主项目Git： 完成剥离后，这些依赖的源代码现在可以被主项目Git视为普通文件。你可以在主项目根目录执行git add .，然后提交变更。
cd /path/to/myproject git add . git commit -m "Add vendored Go dependencies"
注意事项与局限性：
- 失去依赖自身的版本控制信息： 一旦.git目录被删除，你就无法直接在这些依赖目录中执行git log或git checkout等命令来查看或切换依赖自身的版本。主项目Git只会跟踪这些文件的当前状态。
- 依赖更新的复杂性： 如果需要更新某个依赖，你需要重新运行go get -u，然后再次执行剥离.git和.gitignore的步骤，再提交到主项目。这会增加维护成本。
- 不适用于精细化版本控制： 这种方法将所有依赖的源代码“扁平化”地纳入主项目Git，不利于对单个依赖进行精细化的版本管理和回溯。
- 构建可重复性： 尽管将依赖源代码纳入主项目Git确保了代码的完整性，但如果未来需要重新构建项目，仍需确保go get下载的版本与当前提交的版本一致。在Go Modules普及之前，这通常需要额外的工具（如goven等）来锁定依赖版本。
git submodule的适用性分析
git submodule是Git提供的一种管理子项目的方式，它允许将一个Git仓库作为另一个Git仓库的子目录。初看起来，这似乎是解决“双重Git”问题的理想方案。然而，对于go get引入的第三方依赖，git submodule通常不是一个合适的选择。
- 设计理念不符： git submodule主要用于管理你自己的相关子项目，例如一个大型项目中的独立组件或库。它期望你对子模块有完全的控制权，并手动管理其版本和更新。
- go get的工作方式： go get命令的设计初衷是自动化地获取和安装Go包，它并不关心也不使用git submodule机制。你无法指示go get将依赖添加为子模块。
- 管理成本高昂： 如果你尝试为每一个通过go get引入的第三方依赖手动设置git submodule，那么随着项目依赖数量的增加，维护成本将变得极其高昂且不切实际。你将不得不手动跟踪每个依赖的URL和版本，并将其添加到.gitmodules文件中。
因此，对于Go语言的第三方依赖管理，git submodule并非推荐的解决方案。
总结与现代实践展望
剥离go get下载的依赖仓库中的.git元数据，并将其作为普通文件纳入主项目Git管理，是一种直接且在特定场景下有效的解决方案。它简化了主项目Git的结构，确保了所有项目代码（包括依赖）都在一个Git仓库中。然而，这种方法存在维护成本高、失去依赖自身版本控制信息等局限性。
值得注意的是，在Go 1.11版本引入Go Modules之后，Go语言的依赖管理方式发生了根本性变化。Go Modules通过go.mod和go.sum文件来声明和锁定项目依赖，并支持将依赖源代码直接存储在vendor目录中，而无需保留其内部的.git目录。这种机制从根本上解决了“双重Git”问题，并提供了更优雅、可控且可重复的依赖管理方案。
对于遗留项目或在无法使用Go Modules的特定环境中，上述剥离.git元数据的方法仍具有参考价值。但在新的Go项目开发中，强烈建议采用Go Modules进行依赖管理，以获得更好的开发体验和项目可维护性。
