管理源代码管理中的共享代码

Question

项目A和B都使用图书馆项目L：

从人们在网上发表的文章来看，管理这种情况似乎令人头痛：

http://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/ 为什么你不应该使用汞子程序

是否有任何避免困难的解决办法，例如：

·失去工作是因为VCS做了一些意想不到的事情

·地狱式潜水艇合并

·VCS导致的混乱指向子模块的意外版本，

因为用户没有意识到已经发生了这种情况，所以更糟的是

Answer 1

绝对没有理由避免git submodule；它比大多数替代的“解决方案”要好得多。只需让您的构建脚本断言(但不是修改；以解决问题1)子模块是存在的和最新的(解决问题3)，并且只对子模块进行修改作为它自己的回购，而不是好像它是主要回购(解决问题2)的一部分。我要重复一遍:只对子模块进行修改，将其作为自己的回购。

此外，最近版本的git提供git submodule update --remote，以自动从您正在跟踪的分支中提取最新版本。

假设您没有完全忽略所有时候最重要的git命令git status (在运行git commit时它的输出也包含在编辑器中)，那么您就不会有任何问题。

当然，如果您使用的是GUI前端，这可能是垃圾，但不管您是否使用子模块，这都是事实。