项目布局:
/project_a
/shared
/project_b
/shared
/shared
project_a和project_b都需要包含共享文件夹。使用svn,我们使用了svn:externals,它工作正常,因为svn可以引用子目录(也有相对路径)。但是,我们转移到git,它似乎不支持检查子目录。
我们现在的解决方案是将project_a,project_b和all共享放在不同的git repos中,并在project_a和project_b中使用git子模块。然而,这似乎比使用svn:externals的单片svn repo复杂得多。在git中处理常见元素的正确方法是什么?
编辑: 共识是子模块是要走的路。但是使用它一天,使用它似乎非常不友好。
在对共享文件进行更改后,我必须:
与svn中的单个提交相比,这看起来更复杂。缺少其中一个步骤会导致巨大的版本混乱。我在这里错过了什么吗?
答案 0 :(得分:1)
子模块是正确的答案。
您不保留SVN的单一方法的事实是pretty much by design with a DVCS(您将存储库标记为 all )。
这允许您引用精确配置(请参阅submodules true nature),即您将始终引用精确的SHA1引用(而不是svn external,您无需指示修订版本数)。