複数のサブプロジェクトでプロジェクトを分離する場合
私が取り組んでいるプロジェクトを1つではなく2つのリポジトリに分割することが理にかなっているかどうかを知りたいです。 私が言えることから： フロントエンドはhtml + jsで記述されます .netのバックエンド バックエンドはフロントエンドに依存せず、フロントエンドはバックエンドに依存しません フロントエンドは、バックエンドに実装された安らかなAPIを使用します。 フロントエンドは、任意の静的httpサーバーでホストできます。 現在、リポジトリは次の構造を持っています。 ルート： フロントエンド/* バックエンド/ * 両方のプロジェクトを同じリポジトリに保持するのは間違いだと思います。両方のプロジェクトは相互に依存関係を持たないため、個々のリポジトリと、必要に応じてサブモジュールを持つ親リポジトリに属する必要があります。 私はそれは無意味であり、それを行うことで利益を得ることはないと言われました。 私の議論のいくつかを以下に示します。 相互に依存しない2つのモジュールがあります。 長期的に両方のプロジェクトのソース履歴があると事態が複雑になる可能性があります（探しているバグとはまったく関係のないコミットの半分がある間にフロントエンドで何かを探してみてください） 競合とマージ（これは起こらないはずですが、誰かがバックエンドにプッシュすると、他の開発者がバックエンドの変更をプルしてフロントエンドの変更をプッシュすることになります。） 1人の開発者はバックエンドでのみ作業するかもしれませんが、常にフロントエンドを引っ張る必要があります。 長い目で見れば、いつ配備するのか。何らかの方法で、フロントエンドを複数の静的サーバーにデプロイし、バックエンドサーバーを1つ持つことができます。いずれの場合も、バックエンド全体を複製するか、すべてのサーバーにフロントエンドのみをプッシュするか、バックエンドを削除するカスタムスクリプトを作成する必要があります。1つだけが必要な場合は、両方よりもフロントエンドまたはバックエンドのみをプッシュ/プルする方が簡単です。 反論（1人が両方のプロジェクトで作業する可能性があります）、サブモジュールで3番目のレポを作成し、それで開発します。履歴は個々のモジュールに分けられており、バックエンド/フロントエンドのバージョンが同期して実際に連携するタグをいつでも作成できます。フロントエンドとバックエンドの両方を1つのリポジトリにまとめても、それらが連携して機能するわけではありません。両方の履歴を1つの大きなレポにマージしているだけです。 サブモジュールとしてフロントエンド/バックエンドを使用すると、プロジェクトにフリーランサーを追加する場合に物事が簡単になります。場合によっては、コードベースへの完全なアクセス権を実際に与えたくないことがあります。「外部者」が表示/編集できるものを制限したい場合、1つの大きなモジュールがあると事態が難しくなります。 バグの紹介とバグの修正のために、フロントエンドに新しいバグを挿入しました。その後、誰かがバックエンドのバグを修正します。1つのリポジトリで、新しいバグの前にロールバックすると、バックエンドもロールバックされ、修正が困難になる可能性があります。フロントエンドのバグを修正しながらバックエンドを動作させるには、別のフォルダにバックエンドをクローンする必要があります...その後、物事を再マージしようとします... 1つのリポジトリのHEADを移動するので、2つのリポジトリを作成するのは簡単です他を変更しないでください。また、異なるバージョンのバックエンドに対するテストは簡単です。 誰かが私を説得するためにもっと議論をすることができますか、少なくともプロジェクトを2つのサブモジュールに分けるのが無意味な（より複雑な）理由を教えてください。プロジェクトは新しく、コードベースは数日前のものなので、修正するのに早すぎません。