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

Question

我终于将GitHub和Composer依赖管理集成到我的工作流中。这无疑是向前迈出的一大步，尽管我仍然对GIT管理“嵌套”依赖关系感到非常困惑。

由于我使用的是一个令人敬畏的Wordpress Stack根目录/基岩，我简化的目录结构如下所示：

|-- /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

"Subrepositories“在项目根目录的composer.json中定义，并由composer install从GitHub下载。到目前一切尚好。

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

所以..。有很多关于这个话题的文章，其中大多数都提到了SubModules，但是如果我正确地理解了作曲家的概念，他们之间就会有冲突。

只需使用嵌套的.git存储库似乎对我的情况很好，尽管它似乎不起作用--如果我试图推送/提交嵌套回购，或者“一切都是最新的”，或者我得到了诸如Your branch is ahead by 1 commit. 之类的消息，所以“嵌套它”是不可行的？。

事先谢谢，为这个问题的语气有点混乱而抱歉，我在这个话题上有点溺水了。)如能提供任何帮助，将不胜感激。

Answer 1

我有几个问题，考虑到这一点，下面的答案是相当笼统的。如果你回答我的问题，我很乐意更新它。

1. 作曲家是否在更新时调出回放？还是重新克隆回购？(它是否正在进行更新？)

- If it reclones then using it for updates will risk overwriting your working tree on those subrepos (**use it for install ONLY or remove it all together**)
- If it isn't doing updates (or dependency recursion -- see below), then it is adding unecessary complexity to your project (**remove it and use one of the options below**) 

​

1. composer 实际上是否执行任何依赖项管理(即递归查找嵌套依赖项)？还是简单地将git项目克隆为子文件夹？

- If it is, then yes, **submodules may be innapropriate** for your case, as they are an alternative dependency management system, but if your subprojects also manage their dependencies with submodules then doing a `git clone --recursive` should work for managing them as well 

​

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

- If yes: have a look at option #2: subrepositories
- otherwise: try option #1: submodules
- [there is a third option which I will link to, but I haven't used it so can't explain in detail (comments/edits appreciated)]

​

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

1. 克隆(主要项目) git clone MAIN_URI REPO && cd REPO && git submodule update --init --recursive 在执行更新之前，--init将把配置从.gitmodules复制到. .git/config (如果需要的话)，--recursive将在每个子模块中递归地执行该操作。 或 git clone --recursive MAIN_URI --recursive告诉git更新和插入有关克隆的所有子模块。
2. 更新(将保留未保存的更改)

- Local copy has no un-pushed changes (updates all submodules by default):

git submodule update [LOCAL_DIR_NAME_I ... LOCAL_DIR_NAME_J]

- Local copy has un-pushed changes (updates all submodules by default):

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

1. 出版/推送

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

git push --recurse-submodules=on-demand

备选案文2：次补语

你说过你在使用这种方法时有问题，但我不明白它们是什么。如果可能，请详细说明。

(这本git书也谈到了细分，但我无法为自己的生活找到现在的地方，如果你找到了，请告诉我。)

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。

1. 管理

通过：` `cd LOCAL_DIR_NAME_N‘管理单个子代表并使用普通的git命令

请记住，您的子回购文件的更改将由您的主回购跟踪。

这里最大的问题是克隆(如果你想让冒牌货能够处理子项目)，因为你的子回购.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。如果这个假设是不正确的，那么上面的三个选项都不可能解决你的问题。