web-dev-qa-db-ja.com

GITネストリポジトリ：Composer vs. SubModules vs. Subtree vs.？

私はついに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テーマをテストすることはできません...

だから...どちらに行くの？ ISこのトピックに関する投稿がたくさんあり、そのほとんどがサブモジュールについて言及していますですが、Composer 、それらは互いに矛盾しているようなものです。

ネストされた.gitリポジトリを使用するだけで、私の場合はうまくいくようですが、機能していないようです。ネストされたリポジトリをプッシュ/コミットしようとすると、「すべてが最新です」またはYour branch is ahead by 1 commit.などのメッセージが表示されます。 つまり、「ネストする」だけではダメですか？

事前に感謝し、質問の口調が少し混乱して申し訳ありませんでしたが、私はトピックに少し溺れました。 :)どんな助けでも大歓迎です。

gitnestedcomposer-phpgit-submodulesgit-subtree
21
Petr Cibulka

いくつか質問がありますが、それを考慮すると、以下の答えは非常に一般的です。私の質問に答えていただければ、喜んで更新します。

  1. composerは更新時にリポジトリをプルしますか？ ORリポジトリを再クローン化しますか？ （更新も行っていますか？）

    • 再クローン化した場合、更新に使用すると、それらのサブリポジトリで作業ツリーが上書きされるリスクがあります（インストールのみに使用するか、すべて一緒に削除します）
    • 更新（または依存関係の再帰-以下を参照）を行っていない場合は、プロジェクトに不必要な複雑さを追加しています（プロジェクトを削除し、以下のオプションの1つを使用してください）

  2. composer実際に依存関係の管理を行っていますか（つまり、ネストされた依存関係を見つけるために繰り返し）？それとも、単にgitプロジェクトをサブフォルダーとして複製するだけですか？

    • もしそうなら、はい、サブモジュールは代替の依存関係管理システムであるため、あなたのケースには不適切である可能性がありますが、サブプロジェクトも依存関係を管理している場合サブモジュールを使用する場合は、git clone --recursiveを実行することでそれらを管理することもできます。

  3. マスタープロジェクトでサブプロジェクトへの新しい変更を追跡しますか？

    • はいの場合：オプション＃2：サブリポジトリをご覧ください
    • それ以外の場合：オプション＃1を試してください：サブモジュール
    • [リンクする3番目のオプションがありますが、使用したことがないため、詳細に説明できません（コメント/編集を歓迎します）]

オプション＃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. 更新中（保存されていない変更は保持されます）

    • ローカルコピーにはプッシュされていない変更はありません（デフォルトですべてのサブモジュールを更新します）：

    git submodule update [LOCAL_DIR_NAME_I ... LOCAL_DIR_NAME_J]

    • ローカルコピーにはプッシュされていない変更があります（デフォルトですべてのサブモジュールを更新します）：

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

  3. 公開/プッシュ

これは最初にサブモジュールプッシュを試行し、成功した場合はメインプロジェクトプッシュを実行します

git Push --recurse-submodules=on-demand

オプション＃2： サブリポジトリ

この方法の使用に問題があるとのことですが、それが何であるかわかりません。可能であれば詳しく説明してください。

（gitの本でもサブリポジトリについて説明していますが、今のところどこを見つけることができません。見つけたら教えてください）

  1. 設定：

注：マスターリポジトリは、サブリポジトリの.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：好きなように

もちろん、他の多くのワークフローを設定することもできますが、場合によってはもっと簡単になることもあります。たとえば、dep管理にComposerを使用して、メインプロジェクトの外部でサブプロジェクトのクローンを作成し、メインプロジェクトに追跡されていないシンボリックリンクを作成して、簡単にアクセスできるようにすることができます。メインプロジェクトで作業するときのこれらのファイル。これはスクリプトで自動化できます（これらすべてのリポジトリのバッチプッシュも同様です）。おそらく、composer.jsonを解析して、新しい（gitベースの）依存関係に対してこれを自動的に行うこともできます。

注：Composerを使用する必要はまったくないようです。この仮定が正しくない場合、上記の3つのオプションのいずれも問題を解決しない可能性があります。

31
DylanYoung