git - サブプロジェクトでの Git 自動チェックアウト

Question

私の会社ではSVN からGitへの移行を楽しんでおり、ワークフローと開発プロセスをより効果的にするために再考しています。

プロジェクト間の依存関係の説明は次のとおりです。

first_app/
└── first_specific_dep
    └── common_dep

second_app/
└── second_specific_dep
    └── common_dep

特にブランチから別のブランチに切り替えるときに、Git 内の依存関係を表すより良い方法を探しています。

すべての開発プロセスを快適に行うには、ルートプロジェクトのgit チェックアウトがサブプロジェクトの他のすべてのチェックアウトを自動的に実行することが望ましいので、テスト担当者は依存関係のブランチが何であるかについて心配する必要がありません。

score 1 · Accepted Answer

残念ながら、この状況に特効薬はありません。その問題を解決するために Git サブモジュールを使用しようとした人もいますが、私の知る限り、成功はまちまちです。（ただし、私自身は経験がないので、他のオプションを歓迎します。）

私の現在の会社では、CVS から Git に移行したばかりで、同じ課題に直面しています。私たちが学んだ2つの実用的なガイドラインがあります。

機能ブランチが複数のリポジトリに関係することが多い場合は、リポジトリをマージするか、コードを再編成することを検討する必要があります。大まかなガイドラインとして、機能の開発の 90% 以上を 1 つのブランチで行うことを目指す必要があります。そうしないと、機能が大きすぎるか、(リポジトリの背後にある) コンポーネントが適切に分離されていません。
プロジェクト間でそれらを共有することは避けられないため、ユーティリティ関数は確かに問題です (それが目的です)。ただし、ほとんどの場合、それらは比較的安定している必要があります。フィーチャーブランチ内で開発を行っている場合、ユーティリティ関数を変更する必要が生じることは比較的まれです。

つまり、コードの論理構造が優れているほど、問題に遭遇することが少なくなります。

最後に、リポジトリを分割するかどうか迷った場合は、1 つのリポジトリに残すことをお勧めします。ただし、巨大なコードベースがある場合は、1 つの大きなリポジトリを使用することはお勧めしません。プッシュは早送りではないとして拒否されることがよくあります。

また、Git の上にいくつかのスクリプトを構築して、すべての依存関係を持つプロジェクトを簡単にチェックアウトできるようにしますが、これも環境に大きく依存します。

1 に答える 1