GIT嵌套存储库:Composer vs. SubModules vs. Subtree vs.？

Question

我终于在我的工作流程中加入了GitHub和Composer依赖管理.这绝对是一个巨大的进步,虽然我仍然对GIT管理"嵌套"家属感到困惑.

当我使用一个很棒的Wordpress Stack ROOTS/BEDROCK时,我的简化目录结构如下所示:

|-- /project
|   |-- /.git                    // git repository for the skeleton/stack of the project
|   |-- composer.json            // list of dependencies, most of them are my own repositories on GitHub
|   |-- /vendor
|   |   |-- /php-dependency-1    // 3rd party dependencies not directly related to Wordpress
|   |-- /web
|   |   |-- /app                 // acts as "wp-admin" folder
|   |   |   |-- /mu-plugins       
|   |   |   |   |-- /SUBREPOSITORY-1    // my own framework feature, public, GitHub
|   |   |   |   |-- /SUBREPOSITORY-2    // my own framework feature, public, GitHub
|   |   |   |-- /plugins
|   |   |   |   |-- /SUBREPOSITORY-3    // my own plugin, public, GitHub
|   |   |   |-- /themes
|   |   |   |   |-- /SUBREPOSITORY-5-PARENT-THEME    // parent theme used on my framework, public, GitHub
|   |   |   |   |-- /SUBREPOSITORY-6-CHILD-THEME     // work for client, private, BitBucket
|   |   |-- /wordpress           // Wordpress CMS
|   |   |   |-- /wp-admin
|   |   |   |-- /wp-includes

"子库"在我composer.json的项目根目录中定义,并从GitHub下载composer install.到现在为止还挺好.

但!我希望能够调整我的parent-theme一些mu-plugins,我需要能够从我的每个项目中推送/提交它们.如你所知,没有wordpress安装,你无法真正测试wordpress主题......

那么......走哪条路？有很多关于这个主题的帖子,其中大多数都提到了SubModules,但是如果我正确地理解了Composer,它们就会彼此冲突.

只是使用嵌套的.git存储库看起来很适合我的情况,尽管它似乎不起作用 - 如果我尝试推送/提交嵌套的repo,或者"一切都是最新的"或者我得到的消息Your branch is ahead by 1 commit. 如此只是"嵌套它"是不是一个人？

提前谢谢,对于这个问题的一点点混乱的语气感到抱歉,我在主题中淹了一点.:) 任何帮助将非常感激.

Answer 1

我有几个问题,考虑到这一点,下面的答案非常通用.如果你回答我的问题,我很乐意更新.

1. 作曲家是否会在更新中提取回购？还是重新回复了回购？(它甚至在做更新吗？)

   • 如果它重新连接然后使用它进行更新将有可能覆盖那些子目录上的工作树(仅用于安装或一起删除它)
   • 如果它没有进行更新(或依赖性递归 - 见下文),那么它会为您的项目添加不必要的复杂性(删除它并使用下面的选项之一)

2. 作曲家实际上是在做任何依赖管理(即递归以找到嵌套的依赖关系)吗？或者它只是将git项目克隆为子文件夹？

   • 如果是,那么是的,子模块可能不适合您的情况,因为它们是一个替代的依赖管理系统,但如果您的子项目也管理它们与子模块的依赖关系,那么做一个git clone --recursive应该也可以管理它们

3. 您是否希望主项目跟踪子项目的新更改？

   • 如果是:请查看选项#2:子存储库
   • 否则:尝试选项#1:子模块
   • [我将链接到第三个选项,但我没有使用它,所以无法详细解释(评论/编辑赞赏)]

选项#1:子模块

您还可以通过cd LOCAL_DIR_NAME_I并使用常规git命令管理单个子模块

1. 配置:

git submodule add REMOTE_URI_1 LOCAL_DIR_NAME_1
...
...
git submodule add REMOTE_URI_N LOCAL_DIR_NAME_N
git commit -m "Add submodules..."

2. 克隆(主要项目)

   git clone MAIN_URI REPO && cd REPO && git submodule update --init --recursive

   --init在执行更新(如有必要)之前,--recursive将配置从.gitmodules复制到.git/config,并将在每个子模块中递归执行该操作.

   要么

   git clone --recursive MAIN_URI

   --recursive 告诉git更新并初始化克隆的所有子模块

3. 更新(将保留未保存的更改)

   • 本地副本没有未推送的更改(默认情况下更新所有子模块):

   git submodule update [LOCAL_DIR_NAME_I ... LOCAL_DIR_NAME_J]

   • 本地副本具有未推送的更改(默认情况下更新所有子模块):

   git submodule update --remote --rebase [LOCAL_DIR_NAME_I ... LOCAL_DIR_NAME_J]

4. 出版/推

这将首先尝试子模块推送,如果成功则执行主项目推送

git push --recurse-submodules=on-demand

选项#2:子存储库

你说你使用这种方法有问题,但我不明白它们是什么.请尽可能详细说明.

(git书也讨论了subrepos,但我不能为我的生活找到现在的地方;如果你找到它,请告诉我)

1. 配置:

注意:主仓库不会跟踪subrepo的.git更改,只跟踪文件自身的更改

目录名后面的斜杠(/)对于避免创建子模块至关重要

git clone REMOTE_URI_1 LOCAL_DIR_NAME_1 && git add LOCAL_DIR_NAME_1/
...
...
git clone REMOTE_URI_N LOCAL_DIR_NAME_N && git add LOCAL_DIR_NAME_N/
git commit -m "Add subrepos..."

如果使用Composer :(并且它正在为您执行克隆),您可以简单地执行添加和提交,但也许您可以配置composer来执行此操作.

2. 管理

通过以下方式管理单个子部分: `cd LOCAL_DIR_NAME_N'并使用普通的git命令

请记住,您的主仓库将跟踪您的子版本文件的更改

这里最大的问题是克隆(如果你希望colaborator能够处理子项目),因为你的subrepo .git文件没有被跟踪.在每个存储遥控器的子库中包含一个文件remote.info应该解决这个问题.然后在主仓库中添加一个脚本,用于每个子目录cd SUBDIR && git init && cat remote.info | xargs git remote add origin.根据Composer正在做什么(请参阅上面的问题),您可能需要composer update向此脚本添加命令

选项#3:子树合并

我对这种方法的细微之处并不完全有信心,所以我只想链接到它

试试这个链接以获得一些教程

选项#N:你想要的任何方式

当然,您可以设置许多其他工作流程,在某些情况下可能更简单.例如,您可以坚持使用Composer进行dep管理并在主项目之外克隆子项目,在主项目中创建未跟踪的符号链接,以便在处理主项目时轻松访问这些文件.这可以通过脚本自动执行(也可以批量推送所有这些repos).您甚至可以解析composer.json以自动为新的(基于git的)依赖项执行此操作.

注意:在我看来,您根本不需要使用Composer.如果这个假设不正确,则上述3个选项中没有一个可以解决您的问题.