GitHub の 1 つのリポジトリに iOS / Android / Web / バックエンドのプロジェクトを同居させて開発を進めると一体どうなるのか？

1 リポジトリで一緒くた開発のメリット

• あれば知りたいです 🙇‍♂️
  • 「他領域の変更内容が develop や release ブランチにマージされるのでリリース時の全体の差分がまとめて確認できるのと足並みが揃ってわかりやすいのではないか」と仰っている方はいらっしゃいました

1 リポジトリで一緒くた開発のデメリット

1. GitHub Actions の設定が面倒くさくなるとの。例えばバックエンド側で用いたい場合など個別指定がそもそもできるのかも不明。
2. コミット履歴が人間には読めない状態になっている。自分の担当領域以外のコミットとマージが大量に視界に入るため、例えば Android だけの状況を過去を遡って確認することは容易ではない（履歴を見やすくする方法をご存知の方がいらっしゃればご教示いただきたいです 🙏 ）。それ故にか「 develop のモジュールに次回リリースの修正内容が漏れなく含まれているか動作確認してほしい」という依頼が PM から来て辛い。Android 単独のリポジトリであれば Sourcetree で履歴を目視すれば Pull Request が develop ブランチにマージされていることは GUI で一目瞭然。万が一 Pull Request が誤ったブランチにマージされてしまったとしても Simple is best な Android だけのリポジトリであれば早期に気づくことができる筈。 develop に向けてマージされている GitHub の Pull Request の URL をエビデンスとして提示すればいいのかもしれませんが面倒くさい。
3. Git-flow を適用することができない。iOS / Android / Web / バックエンドの修正内容が main と develop と release にマージされるのですが、クライアントとサーバーのリリース時期が異なる場合に Release の終了（ release を main と develop にマージしてタグを打つ）をする訳にはいかない。 develop_ios や develop_android ブランチを作ればいいのではないかというアイデアを思いつきましたが、そんなことをするのであれば OS 毎にリポジトリを作って分ければいいのでは？と思ってしまいました。アプリとサーバー共に公開されるまで release を main にマージしないという暫定的なブランチ戦略が採用されることになりました。事故が起こらないように気をつけてください 👮
4. デグレーションが発生しがち。バックエンド側に不具合が見つかり以前の状態に戻すためにコミット履歴をリバートすると iOS のコミット内容まで失われてしまい気付かずそのまま iOS アプリがリリースされるという事案がありました。Git-flow を採用する前の話なのでブランチ戦略が存在しなかったことが問題なのかもしれませんが。あとテストを書けておらず検知できなかったのもよくはないですが。テスト コードごと打ち消されてしまうと厳しいですかね 🧐

1 リポジトリに詰め込みが発生した経緯