シナリオは次のとおりです。私は 1 つの iOS アプリケーションから始めた会社で働いています。現在、同社は、同じコード ベースの大部分を共有する 2 つ目の iOS アプリケーションの作成に関心を持っています。元のアプリケーションは、再利用できるようにすることを意図して作成されたものではありません。その時点では、2 番目の同様のアプリケーションが作成されることは知られていませんでした。将来的には、既存のコード ベース上に構築される同様のアプリケーションがさらに増える可能性があります。
ソースコードを今後どのように維持するかに関して、「最良の」オプションを決定しようとしています。したがって、私たちが検討しているオプションには、共有ライブラリを含む単一のリポジトリ、共有ライブラリ用の 1 つのリポジトリとすべての iOS アプリケーションを含む 1 つのリポジトリ、共有ライブラリ用の 1 つのリポジトリと iOS アプリケーションごとに 1 つのリポジトリなどがあります。複数のリポジトリなどを使用する場合、git サブモジュールを使用するかどうかの問題。
現在、2 つのアプリケーション + ライブラリはすべて 1 つの git リポジトリにあります。これの利点の 1 つは、開発者が単一のリポジトリのコミットをチェックアウトして、複数のリポジトリを更新することを心配することなく、製品がビルドされることを期待できることです。基本的に、開発者は、複数のリポジトリが互いにロックステップで移動する必要があることや、ビルドが機能するためにリポジトリ コミットの特定の組み合わせが必要であることを気にする必要はありません。開発者は、別の開発者が 1 つのリポジトリをコミットすることを覚えていて、他のリポジトリはコミットしていないというケースについても心配する必要はありません。
ここに私が考慮したいくつかの事柄があります：
サブモジュール
以前にサブモジュールを使用したことがありますが、専門家ではありません。私の理解では、サブモジュールを含む「スーパー」リポジトリには、サブモジュールの特定のコミットへの参照も格納されています。これは、複数のリポジトリ (つまり、アプリケーション + ライブラリ) がロックステップで移動することを保証することを部分的に扱いますが、サブモジュールから変更を手動でプルする必要があるという問題がまだあると推測しています。また、開発者がたまたま変更をプッシュするのを忘れ、スーパー リポジトリによって参照された場合、サブモジュール コミットをプルすることができないという問題があります。
サブモジュールの優れた点の 1 つは、ライブラリと、たまたまライブラリを使用するアプリケーションとの間に、より強力なセマンティック分離を作成することです。これが実際に役立つかどうかはわかりません。
単一のリポジトリ
前述のとおり、これが現在行っていることです。2 つのアプリケーション + 共有ライブラリ コードのすべてが 1 つのリポジトリに。最大の懸念は、プロジェクト 1 および 2 とライブラリの間の変更を分離する機能が比較的存在しないことです。たとえば、誰かが 1 回のコミットでライブラリ コードとアプリケーション コードの両方を変更したとします。次に、別の開発者がライブラリ コードの変更を要求します。
単一リポジトリの優れた点の 1 つは、すべてがロックステップで移動することです。複数のリポジトリ バージョンを一致させることを心配する必要はありません。XCode ワークスペースを使用している場合は、2 つのアプリケーション間でリファクタリングも可能です。
分岐
もう 1 つのオプションは、コードを管理するために、単一または複数のリポジトリで何らかの分岐モデルを使用することです。
最終的には、2 つ以上の iOS アプリケーションと共有ライブラリ コードを管理するための優れたモデルを見つけようとしているだけです。これが複数のリポジトリ、サブモジュール、分岐モデル、またはその他によって達成されるかどうか。さまざまなオプションの長所と短所に関する一般的な提案はありますか?