假设我有一个类似的仓库
repoX
|_ pkgA
|_ pkgB
|_ pkgC
是否可以将pkgC
中的repoX
用作repoY
中的git子模块?
repoY
|_ pkgX
|_ pkgC (-> repoX)
约束:
repoX
和repoY
是私有的pkgABC
是纱线工作区repoX
不应仅repoY
中的pkgC
用户完全访问答案 0 :(得分:0)
我认为通常有3种处理方式:
#1 git子模块解决方案:git子模块要求您具有顶级pkgC
存储库。您可以定期使用git-filter-repo来生成它,建议使用git filter-branch
。想法:
set -x
set -e
git clone repoX repoX-to-rewrite
git -C repoX-to-rewrite filter-repo--subdirectory-filter pkgC/
git -C repoY submodule add repoX-to-rewrite pkgC
此解决方案具有各种缺点,我强烈建议不要这样做。它要求您重写历史记录。最重要的是,它涉及破坏性操作filter-repo/filter-branch
,并且可能会出错。
#2 git子树:您可以使用git subtree
解决此问题。优点是,它可以完全提取历史记录,易于使用,并且我个人更喜欢它而不是子模块。这个想法如下:
set -x
set -e
# split a subtree. this is a save operation
git -C repoX subtree split -b upstream-pkgc pkgC
# add to repoY
git -C repoY subtree add --prefix pkgC ../repoX upstream-pkgc
## to update
# split a subtree and then merge it into repoY. this should be a fast-forward since
# subtree splits are stable.
git -C repoX subtree split -b upstream-pkgc pkgC
git -C repoY subtree pull --prefix pkgC ../repoX upstream-pkgc
这是一个很好的解决方案。您的脚本可能还需要处理一些其他细节,并提供一些选项供您选择(例如,您是否要使用--squash
),但通常情况下可以正常工作。
#3 pkg管理:根据您使用的pkg管理器,您可以将pkgC发布到内部托管程序包注册表,然后使用yarn之类的东西将其从中拉出。如果您有这种选择,那可能是最自然的选择,不需要git咒语。