[[285646]]

序文

会社は、全部門が接続する必要のある社内システムを開発する必要がありました。社長が自らチームを選出し、期限も迫っていたため、100人を超える大規模なグループが結成されました。

多くの人が関わると、最も単純なことでも複雑になりますが、開発の世界でも同じことが言えます。

問題点

数百人が参加する大規模プロジェクトでの共同作業に Git を使用する場合は、次のような問題点を考慮してください。

• プロジェクトが大きすぎるため、各人のクローン作成時間が長すぎます。
• しばらくコードを取得しないと、取得を待機している更新が何百もあることがわかります。
• 1 人がエラーを送信すると、他の何百人もの人が待機状態になります (私の個人的な経験に基づく)。
• コードのバックトラッキングは困難であり、特定の変更記録を見つけるのは干し草の山から針を見つけるようなものです。

解決

ここで Git サブモジュールが役に立ちます。

もちろん、まず最初に必要なのは合理的なアーキテクチャです。会社の機密保持ポリシーにより、プロジェクトの詳細はここに掲載できません。この記事では主に、サブモジュールの連携における使用方法について説明します。

プロジェクト構造

プロジェクトの主な構造は、おおよそ次のようになります。

 └── 出典 
 ├── layout // 共通レイアウトディレクトリ 
 ├── public // パブリックページディレクトリ 
 ├── router // ルーターのエントリポイント 
 ├── コンポーネント // 一般的なコンポーネント 
 ├── modules // モジュールプロジェクト開発ディレクトリ（サブモジュール）  
 | ├── tms // サブモジュールが必要です 
 | │ ├── components // モジュールの一般的なコンポーネント 
 | │ ├── pages // モジュールページ 
 | │ ├── router // モジュールルーティング 
 | │ └── store // モジュールVuexデータ 
 | └── ... // サブモジュール 
 ├── app.vue // コンポーネント 
 └── main.js // プロジェクトのエントリポイント

部門ごとにサブモジュールを1つずつ作成します。各サブモジュールには、master（本番環境）ブランチとdev（開発環境）ブランチが含まれている必要があります（Gitflowワークフローを推奨）。

開発プロセス

クローンプロジェクト

他のWebpackプロジェクトと同様に、srcにはビジネスロジックコードのみが含まれ、開発設定はsrcの外部に配置されます。そのため、開発環境を実行するには、まずメインプロジェクトをクローンする必要があります。

 $ git クローン https://github.com/test/main.git

サブモジュールを追加

もちろん、通常は開発にmasterブランチを使用しません。正しいアプローチは、プロジェクトをクローンし、すぐにdevブランチをベースに開発ブランチに切り替えることです（原則として、ビジネスチームはメインプロジェクトの開発に集中する必要はありません。これはアーキテクチャチームの責任です。ただし、コードを最新に保ち、サブモジュールをdevブランチに追加・マージするために、メインブランチのdevに切り替えます）。

 $ git checkout -b dev origin/dev

この時点で、プロジェクトに既にサブモジュールがある場合、`modules` フォルダには個々のサブモジュールが含まれていますが、これらのディレクトリは現在空です（予想通り、他のモジュールに注目する必要はありません）。また、プロジェクトのルートディレクトリには、以下の内容を含む `.gitmodules` ファイルがあります。

 [サブモジュール "modules/suba"]  
パス= modules /suba  
 URL = https://github.com/test/suba.git

これはサブモジュールの関連付けファイルです。サブモジュールが追加されるたびに新しいレコードが追加されます。Gitサブモジュールを初めて追加する場合は、自動的に生成されます。

開発環境をセットアップしたら、サブモジュールを関連付ける必要があります。

 $ git サブモジュールを追加 https://github.com/test/subb.git modules/subb

サブモジュールを初めて追加する際は、プロジェクト全体が取得されます。module/subb フォルダを開くと、サブモジュールプロジェクト全体が表示されます。同時に、新しいサブモジュールレコード modules/subb が .gitmodules に追加されます。

サブモジュールを編集

同様に、サブモジュールのマスターブランチにも編集を加えないでください。この時点で、サブモジュールをdevベースの開発ブランチに切り替える必要があります。

サブモジュールディレクトリに移動します。

 $ cd モジュール/subb/  
 $ git checkout -b feature/some-change origin/dev

サブモジュールに変更を加えた後、その変更をリモート リポジトリにプッシュします。

 $ git commit -am 'テストコミットサブモジュール'  
 git チェックアウト dev  
 $ git マージ機能/いくつかの変更 
 $ git プッシュ origin dev  
 $ git ブランチ -d 機能/変更点

この時点で、サブモジュールの変更はリモートリポジトリにコミットされています。ただし、メインプロジェクトのルートディレクトリに移動して差分を確認すると、メインプロジェクトにもいくつかの変更が加えられていることがわかります。

 $ cd ../../  
 $ git diff  
 > diff --git a/subb b/subb  
インデックス 433859c..b78179a 160000  
 --- a/subb  
 +++ b/subb  
 @@ -1 +1 @@  
 -サブプロジェクトコミット 433859c90e539d2a1b9fda27b32bef0d0acae9e6  
 +サブプロジェクトコミット b78179adab252a524ff2a41d6407a7daa6dad34f

これは、サブモジュール「subb」を変更してコミットしたにもかかわらず、メインプロジェクトのポインタがまだ古いコミットIDを指しているためです。この変更をコミットしないと、メインプロジェクトをプルし、「git submodule update」を使用してサブモジュールを更新した他のユーザーは、変更前のコードをプルしてしまいます。Gitコミットガイドラインについて

したがって、この時点でメイン プロジェクトも送信する必要があります。

 $ git commit -am "テストコミットサブモジュール"  
 $ git プッシュ origin dev

これですべての変更の送信が完了します。

新メンバーが参加

新しいメンバーがサブモジュールに参加し、コードを取得する必要がある場合:

 $ git クローン https://github.com/test/main.git  
 $ git checkout -b dev origin/dev  
 $ gitサブモジュールの初期化 
 $ git サブモジュール更新 subb

`git submodule update [サブモジュール名]` は、プルするサブモジュールを指定するコマンドです。すべてのサブモジュールを更新する必要がある場合は、`git submodule update` のみを使用します。通常、共同作業では、自分のモジュールのみに焦点を当てます。

その後、新しいメンバーは、先ほど説明した開発プロセスを続行できます。

サブモジュールを削除

もちろん、要件の変更やエラーの追加などにより、サブモジュールを削除する必要が生じる場合もあります。ただし、Gitにはサブモジュールを直接削除するコマンドがないため、関連するファイルを段階的に削除する必要があることに注意してください。

バージョン管理でサブモジュールを削除する:

 $ git rm -r モジュール/サブ

エディターで次の関連コンテンツを削除するか、コマンド `vi .gitmodules` を使用して Vim で削除することもできます。

 [サブモジュール "modules/subb"]  
パス=モジュール/subb  
 URL = https://github.com/test/subb.git  
ブランチ= dev  

エディターで次の関連コンテンツを削除するか、コマンド `vi .git/config` を使用して Vim で削除することもできます。

 [サブモジュール "modules/subb"]  
 URL = https://github.com/test/subb.git  
アクティブ=真 

.git の下のキャッシュされたモジュールを削除します。

 $ rm -rf .git/modules/subb

次に、変更を送信します。

 $ git commit -am "subbを削除"  
 $ git プッシュ origin dev

プロジェクトを公開

開発プロセス全体が完了し、最終的にリリースする時が来たら、メイン プロジェクト内のすべてのサブモジュールを更新する必要があります。

 git チェックアウト マスター 
 $ git pull origin マスター 
 $ gitサブモジュールの更新 
 $ 糸ビルド

これでプロジェクト全体を公開できます。サブモジュールを共同作業で使うためのガイドはこれで終わりです。ご質問がありましたら、下記にコメントをお寄せください。