GIT嵌套仓库：Composer vs. SubModules vs. Subtree vs.？ [英] GIT Nested repositories: Composer vs. SubModules vs. Subtree vs.?

问题描述

我最终在我的工作流程中加入了 GitHub 和 Composer 依赖关系管理。这绝对是一个巨大的进步，虽然我仍然很困惑的GIT管理嵌套的依赖。

由于我使用一个真棒WordPress堆栈ROOTS / BEDROCK，我简化的目录结构如下：

  |  -  / project 
 | |  -  /.git // git仓库用于项目的骨架/堆栈
 | |  -  composer.json //依赖列表，大多数是我自己的存储库在GitHub 
 | |  -  / vendor 
 | | |  -  / php-dependency-1 //与Wordpress不直接相关的第三方依赖
 | |  -  / web 
 | | |  -  / app //充当wp-admin文件夹
 | | | |  -  / mu-plugins 
 | | | | |  -  / SUBREPOSITORY-1 //我自己的框架特性，public，GitHub 
 | | | | |  -  / SUBREPOSITORY-2 //我自己的框架特性，public，GitHub 
 | | | |  -  / plugins 
 | | | | |  -  / SUBREPOSITORY-3 //我自己的插件，public，GitHub 
 | | | |  -  / themes 
 | | | | |  -  / SUBREPOSITORY-5-PARENT-THEME //在我的框架上使用的父主题，public，GitHub 
 | | | | |  -  / SUBREPOSITORY-6-CHILD-THEME //为客户端，私人工作，BitBucket 
 | | |  -  / wordpress // Wordpress CMS 
 | | | |  -  / wp-admin 
 | | | |  -  / wp-includes 
  

Subrepositories在我的 .json ，并由 composer install 从GitHub下载。到目前为止这么好。

但是！我希望能够调整我的父主题和一些 mu-plugins 很多，我需要能够推/提交从我的每个项目，他们将被包括。如你所知，你不能真正测试wordpress主题没有一个wordpress安装...

那么...哪条路走？ 有很多关于这个主题的帖子，大多数都提到子模块，但如果我正确地理解Composer的想法，他们彼此冲突。

只要使用嵌套的.git存储库似乎很适合我的情况，尽管它似乎不工作 - 如果我尝试推/提交嵌套repo，一切都up 所以只是嵌套它是一个没有去？ / p>

感谢提前，对于一个有点困惑的问题的对不起，我淹死了一个主题。 :)任何帮助将非常感激。

解决方案

我有几个问题，考虑到这一点，是相当通用。如果你回答我的问题，我会很乐意更新它。

1. 作曲家会在更新时提取作品吗？ OR reclone repo？

   
   
   
   
   
   • 如果它重新插入，然后使用它进行更新将有可能覆盖您的工作树在这些子回>
   ）
   
   • 如果没有做更新（或依赖递归 - 见下文），那么它会增加不必要的复杂性
   
   

   • 是作曲家<强>实际做任何依赖管理（即递归找到嵌套依赖）？或者它只是将git项目克隆为子文件夹？

     
     
     
     
     
     • 如果是，那么子模块可能是不适当的对于你的情况，因为他们是一个替代的依赖管理系统，但如果你的子项目也管理其子模块的依赖，然后做一个 git clone --recursive 应该工作，
       
       
     
     

     您希望您的主专案追踪子专案的新变更吗？
     

     
     
     • 如果是：请查看选项＃2：subrepositories
     
     
     • 否则：try option＃1：submodules
     
     
     • [有第三个选项，我将链接到，但我没有使用它所以不能解释详细（评论/编辑赞赏）]
     
     
     
     

选项＃1： cd LOCAL_DIR_NAME_I 您还可以通过 cd LOCAL_DIR_NAME_I 管理单个子模块 / code>并使用正常的git命令

1. 设置：

  git submodule add REMOTE_URI_1 LOCAL_DIR_NAME_1 
 ... 
 ... 
 git submodule添加REMOTE_URI_N LOCAL_DIR_NAME_N 
 git commit -m添加子模块...
  

2. 克隆（主项目）

   
   
   

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

   
   
   

   - init 在执行更新之前从.gitmodules到.git / config的配置（如有必要）， - 递归将在每个子模块中递归执行该操作。

   
   
   

   或

   
   
   

   git clone --recursive MAIN_URI

   
   
   

   - 递归告诉git更新和初始化所有子模块克隆




3. 正在更新（将保留未保存的更改）

   
   
   
   
   
   • 本地副本没有取消更改（默认更新所有子模块） li>
     
   
   
   

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

   
   
   
   
   
   • 本地副本具有未推送的更改（默认情况下会更新所有子模块）：
   
   
   
   $ b b

   git子模块更新--remote --rebase [LOCAL_DIR_NAME_I ... LOCAL_DIR_NAME_J]




4. 发布/推送

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

git push --recurse-submodules =按需

选项＃2：子档案

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

（git的书也谈到subrepos，但我不能为我的生活找到在哪里，我知道如果你找到了）

1. 设置：

注意：master repo不会跟踪子版本的.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 -mAdd subrepos ...
  

如果使用Composer：（它正在为你克隆），你可以简单地做添加和提交，但也许你可以配置作曲家这样做。

2. 管理

`cd LOCAL_DIR_NAME_N'并使用正常的git命令

请记住，您的subrepo文件的更改将由主仓库跟踪

最大的问题是克隆（如果您希望colaborators能够在子项目上工作），因为您的subrepo .git文件没有被跟踪。包括一个文件，remote.info在每个subrepo存储远程应解决这个。然后在你的主仓库中为每个子目录添加一个脚本 cd SUBDIR&& git init&& cat remote.info | xargs git remote add origin 。根据 Composer 的作用（请参阅上面的问题），您可能需要向此脚本中添加 composer update 命令

选项＃3：子树合并 < h1>

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

尝试此链接了解一些教程

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

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

注意：在我看来，你不需要使用 Composer 。如果这个假设不正确，可能上述3个选项中没有一个会解决你的问题。

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.

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

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

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

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.

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. Does composer pull the repos on an update? OR reclone the repo? (Is it even doing updates?)

   • 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)

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

   • 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

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

   • 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)]

Option #1: Submodules

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

1. Setting up:

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. Cloning (the main project)

   git clone MAIN_URI REPO && cd REPO && git submodule update --init --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.

   or

   git clone --recursive MAIN_URI

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

3. Updating (will preserve unsaved changes)

   • 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]

4. Publishing/Pushing

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

git push --recurse-submodules=on-demand

Option #2: Subrepositories

You've said you have problems using this method, but I don't understand what they are. Please elaborate if possible.

(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. Setting up:

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

The slash (/) after the directory name is essential to avoid creating a submodule

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

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.

2. Management

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

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

Option #3: Subtree Merging

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

Try this link for a bit of a tutorial

Option #N: Any way you want

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.

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屋！