git - GIT嵌套存储库:Composer与SubModules与Subtree与？

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中定义，并通过 composer install从GitHub下载。到现在为止还挺好。

但!我希望对我的 parent-theme和一些 mu-plugins进行很多调整，我需要能够从将包含它们的每个项目中推送/提交。如您所知，如果没有安装wordpress，就无法真正测试wordpress主题...

那么...走哪条路呢？ 关于此主题的文章很多，其中大多数提到SubModules ，但是如果我正确理解Composer的想法，它们之间可能会发生冲突。

只是使用嵌套的.git存储库对我来说似乎很棒，尽管它似乎不起作用-如果我尝试推送/提交嵌套的存储库，要么“一切都是最新的”，要么会收到诸如 Your branch is ahead by 1 commit. 之类的消息，所以“嵌套”它”是不行吗？

在此先感谢您，并对这个问题的语气有些困惑，我对此话题有些不知所措。 :) 任何帮助将非常感激。

Answer 1

我有几个问题，考虑到这一点，下面的答案很普通。如果您回答我的问题，我将很乐意对其进行更新。

Composer 是否在更新中提取存储库？还是重新克隆仓库？ (是否还在进行更新？)

如果重新克隆，则使用它进行更新将有可能覆盖那些子存储库上的工作树(仅将其用于安装或将其全部删除)

如果它没有执行更新(或依赖项递归，请参见下文)，则它将为您的项目增加不必要的复杂性(删除它并使用下面的选项之一)

Composer 是否实际上在进行任何依赖关系管理(即递归以查找嵌套的依赖关系)？还是只是将git项目克隆为子文件夹？

如果是，那么是的，子模块对于您的情况可能是不合适的，因为它们是替代的依赖项管理系统，但是如果您的子项目也使用子模块来管理其依赖项，那么执行git clone --recursive应该可以同时管理它们

是否要您的主项目跟踪子项目的新更改？

如果是:请查看选项＃2:子存储库

否则:尝试选项＃1:子模块

[我将链接到第三个选项，但我没有使用过，因此无法详细解释(赞赏评论/编辑)]

选项1: Submodules

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

设置:

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..."

克隆(主项目)
git clone MAIN_URI REPO && cd REPO && git submodule update --init --recursive--init将在执行更新之前将配置从.gitmodules复制到.git / config(如果需要)，并且--recursive将在每个子模块中递归执行该操作。

要么
git clone --recursive MAIN_URI--recursive告诉git在克隆

时更新和初始化所有子模块

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

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

git submodule update [LOCAL_DIR_NAME_I ... LOCAL_DIR_NAME_J]

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

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

发布/推送

这将首先尝试子模块推送，如果成功则执行主项目推送
git push --recurse-submodules=on-demand
选项2: Subrepositories

您已经说过使用此方法时遇到问题，但我不明白它们是什么。请详细说明。

(git书还讨论了子仓库，但我无法一生找到现在的位置；让我知道是否找到它)

设置:

注意:主存储库将不会跟踪对子存储库的.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来执行此操作。

管理

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

请记住，主仓库会跟踪对子仓库文件的更改

此处的最大问题是克隆(如果您希望colaborator能够在子项目上工作)，因为不会跟踪您的子仓库.git文件。在每个包含远程文件的子仓库中，remote.info文件都应包含此文件，以解决此问题。然后将脚本添加到您的主存储库中，该脚本针对每个子目录 cd SUBDIR && git init && cat remote.info | xargs git remote add origin进行操作。根据 Composer 在做什么(请参见上面的问题)，您可能需要向此脚本添加 composer update命令

Option #3: Subtree Merging

对于这种方法的微妙之处，我并不完全有信心，因此我将其链接为

Try this link for a bit of a tutorial

选项N:您想要的任何方式

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

注意:在我看来，您根本不需要使用 Composer 。如果此假设不正确，则上述3个选项都可能无法解决您的问题。