モノリポとマルチ リポの比較

• 3 分

リポジトリは、作業履歴が保存される場所です。これは通常、git サブディレクトリ内にあります。

コード リポジトリは、どのように整理する必要がありますか? 開発チームは、ソフトウェアとリポジトリの懸念事項を分離することを目指しています。 時間が経つにつれて、コード リポジトリが無関係なコードと成果物で煩雑になることは珍しくありません。

リポジトリの整理に関しては、1 つのリポジトリ (モノリポ) を使用する、または複数のリポジトリ (マルチ リポ) を使用する、という 2 つの主な理念があります。

• モノリポは、すべてのソース コードを 1 つのリポジトリに保持するソース管理パターンです。 これを使用すると、簡単に、すべての従業員が一度にすべてにアクセスできるようになります。 複製して完了です。
• プロジェクトを個別のリポジトリに整理することは、マルチ リポと呼ばれます。

モノリポとマルチ リポの理念の根本的な違いは、チームの共同作業の効率化が何によって可能になるかの違いです。 極端なシナリオのマルチ リポ ビューでは、各サブチームがそれぞれのリポジトリで作業できることが示唆されています。 これを使用すると、生産性を最適化するライブラリ、ツール、開発ワークフローを使用して、それぞれの領域で作業できるようになります。

特定のリポジトリ内で開発されていないものを使用するコストは、たとえ社内の人が作成したとしても、サードパーティのライブラリまたはサービスを使用する場合と同じです。

ライブラリでバグが発生した場合は、対応するリポジトリで対処する必要があります。 新しい成果物を発行したら、リポジトリに戻り、必要なコード変更加えることができます。 ただし、バグが別のコード ベースにあるか、異なるライブラリ、ツール、またはワークフローが関係する場合は、そのシステムの所有者にサポートを求め、応答を待つ必要があります。

モノリポ ビューを使用する場合、複雑な依存関係グラフの管理では、1 つのリポジトリを使用するのが難しくなる可能性があります。 異なるチームが独立して作業できるようにするメリットは大きくありません。 一部のチームは効率的な作業方法を見つけるかもしれませんが、それがすべてのグループがそうであるとは限りません。 さらに、他のチームが最適でないアプローチを選び、それにより、他のチームが得たメリットが否定される可能性があります。 すべての作業をモノリポに統合することで、この 1 つのリポジトリを注意深く監視することに集中できるようになります。

他のリポジトリに変更を加えたり、チームが自分のために変更を行うのを待ったりする手間は、誰もが何らかの変更をすることができるモノリポでは回避できます。

ライブラリでバグを発見した場合は、独自のコードでバグを見つけるのと同じくらい簡単に修正できます。