GIT 嵌套存储库:Composer vs. SubModules vs. Subtree vs.? [英] GIT Nested repositories: Composer vs. SubModules vs. Subtree vs.?

问题描述

我终于在我的工作流程中加入了 GitHub 和 Composer 依赖项管理.这绝对是向前迈出的一大步，尽管我仍然对 GIT 管理嵌套"依赖项感到非常困惑.

I've finally incorporated GitHub and Composer dependency management on my workflow. It's definitely a huge step forward, although I remain very confused about GIT managing the "nested" dependecies.

由于我使用了一个很棒的 Wordpress Stack ROOTS/BEDROCK，我的简化目录结构如下所示:

As I'm using an awesome Wordpress Stack ROOTS/BEDROCK, my simplified directory structure looks like this:

|-- /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 下载.到目前为止一切顺利.

"Subrepositories" are defined in my composer.json on the root of the project and are downloaded from GitHub by composer install. So far so good.

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

But! I expect to tweak my parent-theme and some mu-plugins a lot, I need to be able to push/commit from each of my projects they will be included. As you know, you can't really test wordpress theme without a wordpress installation ...

那么……该走哪条路?有很多关于这个主题的帖子，其中大部分都提到了子模块，但如果我对 Composer 的理解正确的话，它们就会相互冲突.

So ... which way to go? There IS A LOT of posts about this topic and most of them mention SubModules, but if I get the idea of Composer correctly, they are kind of in conflict with each other.

只使用嵌套的 .git 存储库对我来说似乎很好，尽管它似乎不起作用 - 如果我尝试推送/提交嵌套存储库，要么一切都是最新的"，要么我收到诸如 之类的消息您的分支领先 1 次提交. 所以仅仅嵌套"是行不通的?

Just use nested .git repositories seem great for my case, altough it does not seem to work - if I try to push/commit nested repo, either "everything is up to date" or I get messages such as Your branch is ahead by 1 commit. So just "nesting it" is a no a go?

在此先感谢并抱歉这个问题的语气有点混乱，我在这个话题上有点淹没了.:) 任何帮助将不胜感激.

Thanks in advance and sorry for a little confused tone of the question, I drowned a little in the topic. :) Any help would be much appreciated.

推荐答案

我有几个问题，考虑到这些，下面的答案很笼统.如果你回答我的问题，我会很乐意更新它.

I have a couple of questions, and in consideration of that, the answer below is quite generic. If you answer my questions, I will gladly update it.

1. 作曲家是否会在更新时提取存储库?或重新克隆回购?(它甚至在做更新吗?)

1. Does composer pull the repos on an update? OR reclone the repo? (Is it even doing updates?)

• 如果它重新克隆，那么将其用于更新将有覆盖这些子存储库上的工作树的风险(仅将其用于安装或将其全部删除)
• 如果它没有进行更新(或依赖递归——见下文)，那么它就会给你的项目增加不必要的复杂性(删除它并使用下面的选项之一)

composer 实际上是否在做任何依赖管理(即递归查找嵌套依赖)?还是干脆把git项目克隆成子文件夹?

Is composer actually doing any dependency management (i.e. recursing to find nested dependencies)? Or is it simply cloning the git projects as subfolders?

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

• 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

您希望主项目跟踪子项目的新更改吗?

Do you want your master project to track new changes to your subprojects?

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

选项 #1:子模块

你也可以通过cd LOCAL_DIR_NAME_I和使用普通的git命令

Option #1: Submodules

You can also manage an individual submodule by cd LOCAL_DIR_NAME_I and using normal git commands

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. 克隆(主要项目)

1. Cloning (the main project)

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

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

--init will copy the configuration from .gitmodules to .git/config before performing the update (if necessary), and --recursive will do that action recursively in each submodules.

或

git clone --recursive MAIN_URI

--recursive 告诉 git 在克隆时更新和初始化所有子模块

--recursive tells git to update and init all submodules on cloning

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

Updating (will preserve unsaved changes)

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

git 子模块更新 [LOCAL_DIR_NAME_I ... LOCAL_DIR_NAME_J]

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

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

发布/推送

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

This tries a submodule push first and if successful performs a main project push

git push --recurse-submodules=on-demand

您说过使用这种方法时遇到问题，但我不明白它们是什么.如果可能，请详细说明.

(git 书也谈到了 subrepos，但我一生都找不到在哪里，现在；如果你找到了，请告诉我)

(the git book also talks about subrepos, but I can't for the life of me find where, right now; let me know if you find it)

1. 设置:

注意:主仓库不会跟踪子仓库的 .git 更改，只会跟踪文件本身

NOTE: the master repo will not track changes to subrepo's .git, just to the files themeselves

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

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 来执行此操作.

If using Composer: (and it is doing the clones for you) you can simply do the adds and commit, but maybe you can configure composer to do this as well.

1. 管理

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

Manage an individual subrep by: `cd LOCAL_DIR_NAME_N' and use normal git commands

请记住，您的主存储库会跟踪对子存储库文件所做的更改

Remember that changes to your subrepo files will be tracked by your main repo

最大的问题是克隆(如果您希望合作者能够处理子项目)，因为您的 subrepo .git 文件没有被跟踪.在每个存储遥控器的子仓库中包含一个文件 remote.info 应该可以解决这个问题.然后向您的主存储库添加一个脚本，该脚本为每个子目录 cd SUBDIR &&git 初始化 &&猫远程信息|xargs git remote add origin.根据 Composer 正在做什么(请参阅上面的问题)，您可能希望向此脚本添加 composer update 命令

The biggest issue here is with cloning (if you want colaborators to be able to work on the subprojects) since your subrepo .git files aren't tracked. Including a file, remote.info in each subrepo that stores the remote should solve this. Then add a script to your main repo that does for each subdirectory cd SUBDIR && git init && cat remote.info | xargs git remote add origin. Depending on what Composer is doing (see questions above) you may want to add a composer update command to this script

我对这种方法的微妙之处并不完全有信心，所以我将链接到它

I'm not entirely confident on the subtleties of this method, so I will just link to it

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

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

Of course you could setup numerous other work flows that in some cases might be simpler. For example you could stick with Composer for dep management and clone your subprojects outside of your main project, creating untracked symlinks in the main project to allow easy access to those files when working on the main project. This could be automated with a script (as could a batch push of all these repos). You could probably even parse composer.json to automatically do this for new (git-based) dependencies.

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

Note: It seems to me that you don't need to be using Composer at all. If this assumption is incorrect, it is possible that none of the 3 options above will solve your problems.

这篇关于GIT 嵌套存储库:Composer vs. SubModules vs. Subtree vs.?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！