git submodule的使用问题

Ri0n72Y commented 3 weeks ago

起因是我会在两台不同的电脑上工作，然后惊讶地发现，子模块并没有办法在两个本地repo之间快速使用。我似乎必须在没有添加子模块的项目中再次添加，但这本身又是一个不那么痛快的流程。

参考这篇可爱的文章：https://linuxstory.org/why-never-use-git-submodule/ 以下是AI总结：

Git Submodule 的问题与替代方案大纲

Git Submodule 的问题

底层设计问题：
- 破坏 Git 数据模型
- 不符合 Git 一般规定
- 导致 Git 树状态异常
细节实现问题：
- 常见 Git 操作导致子模块状态异常
- .gitmodules 潜在安全风险

为什么不推荐使用 Git Submodule

复杂性： 难以管理，容易出错。
效率低下： 浪费时间和精力。
替代方案众多： 存在更优的选择。

Git Submodule 的替代方案

Git Subtree：
- 优点：保持子项目独立性，操作简单。
- 适用场景：子项目大小适中，无需频繁交互。
单一仓库：
- 优点：共享 Git 历史记录，管理方便。
- 适用场景：项目规模适中，分支管理简单。
包管理系统：
- 优点：依赖管理清晰，易于维护。
- 适用场景：有合适的包管理器，依赖 API 暴露充分。
多仓库工具 MR：
- 优点：管理多个代码树，灵活度高。
- 适用场景：项目依赖众多，需要复杂管理。
../dependency 目录：
- 优点：简单轻量，易于理解。
- 适用场景：项目初期，依赖少，用户熟悉操作。
临时下载脚本：
- 优点：灵活控制依赖下载。
- 适用场景：依赖使用频率低，无需频繁更新。

总结

Git Submodule 弊端显著： 不推荐使用。
替代方案多样： 根据项目需求选择合适的方案。
建议： 尽量避免使用 Git Submodule，选择更可靠、高效的方案。

Ri0n72Y commented 3 weeks ago

参考该文章：https://forcemz.net/git/2018/03/22/GitSubmoduleRethinking/

该作者认为git子模块主要用于依赖管理，类似yarn.lock将依赖库的版本锁住，保证库的更新不会直接影响到主项目。这和git官方文档推荐的用法又有一定的出入： https://git-scm.com/book/zh/v2/Git-%E5%B7%A5%E5%85%B7-%E5%AD%90%E6%A8%A1%E5%9D%97

子模块允许你将一个 Git 仓库作为另一个 Git 仓库的子目录。它能让你将另一个仓库克隆到自己的项目中，同时还保持提交的独立。在项目中使用子模块的最简模型，就是只使用子项目并不时地获取更新，而并不在你的检出中进行任何更改。

显然git的思路相对更清晰一些，并且我在项目的末尾找到了解决上一问题的方法： https://git-scm.com/book/zh/v2/Git-%E5%B7%A5%E5%85%B7-%E5%AD%90%E6%A8%A1%E5%9D%97#%E5%AD%90%E6%A8%A1%E5%9D%97%E7%9A%84%E9%97%AE%E9%A2%98

再说一遍，这真的不难，只是会让人有点儿困惑。

这确实不难，但真的让人困惑

Ri0n72Y commented 3 weeks ago

子项目中存在.gitignore控制的文件，对于我来说这是node_modules的依赖项，因此在按照官方文档操作后，我得到了如下报错

> git submodule update --init --recursive
Submodule 'demo-react' (https://github.com/digso/demo-react.git) registered for path 'demo-react'
fatal: Unable to find current revision in submodule path 'demo-react'

更加令人困惑了

好消息是我可以暂时不需要管他，子项目和主项目之间并没有引用关系（事实上也没有发挥其作为monorepo的优势），我仍然可以以并列项目的形式去编辑和修改它，这也缓解了vscode对submodule支持困难的问题。

虽然我乐于研究前沿的技术，但git submodule看上去并不是我目前可以驾驭的

denallo commented 3 weeks ago

我在digsomsg中也用到了子模块，原因是我需要从一个外部仓库（WeChatMsg）中提取有用的东西，并且希望能保持对更新的追踪。我的做法是：

将WeChatMsg仓库folk到组织里，因为我需要修改它
将WeChatMsg打包成python包，这需要在里面添加setup.py等脚本，以及一些导出范围的调整
将WeChatMsg作为子模块，添加到digsomsg的3rdparty路径下

由于已经将WeChatMsg打包成python包，digsomsg不需要直接引用WeChatMsg的代码，而是以pip install的形式安装其功能，从而降低了submodule导致的复杂度，使之尽量趋近于以下情况：

在项目中使用子模块的最简模型，就是只使用子项目并不时地获取更新，而并不在你的检出中进行任何更改。

但目前包版本的管理还没怎么做，每次更新WeChatMsg后导出的包版本都是1.0.0

digso / workflow