Magicode logo
Magicode
2

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

少々愚痴多めにはなります 🙇‍♂️

20XX 年、某組織に Android & 時々 iOS アプリの開発者としてジョインしたのですが、iOS / Android / Web / バックエンドの開発が同一の GitHub リポジトリ上で行われていました。

歴代、渡り歩いてきたチームでは iOS / Android / Web / バックエンドはそれぞれ専用のリポジトリが用意されていたので、1 リポジトリでクライアント & サーバー開発を行うスタイルは私の観測上は少数派になります。

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

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

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

  1. コミット履歴が人間には読めない状態になっている。自分の担当領域以外のコミットとマージが大量に視界に入るため、例えば Android だけの状況を過去を遡って確認することは容易ではない(履歴を見やすくする方法をご存知の方がいらっしゃればご教示いただきたいです 🙏 )。それ故にか「 develop のモジュールに次回リリースの修正内容が漏れなく含まれているか動作確認してほしい」という依頼が PM から来て辛い。Android 単独のリポジトリであれば Sourcetree で履歴を目視すれば Pull Request が develop ブランチにマージされていることは GUI で一目瞭然。万が一 Pull Request が誤ったブランチにマージされてしまったとしても Simple is best な Android だけのリポジトリであれば早期に気づくことができる筈。 develop に向けてマージされている GitHub の Pull Request の URL をエビデンスとして提示すればいいのかもしれませんが面倒くさい。

  2. Git-flow を適用することができない。iOS / Android / Web / バックエンドの修正内容が maindeveloprelease にマージされるのですが、クライアントとサーバーのリリース時期が異なる場合に Release の終了( releasemaindevelop にマージしてタグを打つ)をする訳にはいかない。 develop_iosdevelop_android ブランチを作ればいいのではないかというアイデアを思いつきましたが、そんなことをするのであれば OS 毎にリポジトリを作って分ければいいのでは?と思ってしまいました。アプリとサーバー共に公開されるまで releasemain にマージしないという暫定的なブランチ戦略が採用されることになりました。事故が起こらないように気をつけてください 👮


「リポジトリを分割したい」と何回も訴えてはいるのですが、PM の方が非エンジニアなのが理由なのか、性分の問題なのか、大人の事情なのかは切り分けができていないですが、話が中々前に進まないです 😢 技術者が非技術者に対して理解しやすいよう説明するのを怠っているのかもしれません。


Discussion

コメントにはログインが必要です。