そこで、サーバー側とモバイル開発で gitflow ワークフローを使い始めました。テストカバレッジがあり、ビルドの自動化により、機能ブランチはテストが成功するとすぐに開発ブランチにマージされるため、サーバー側のコードで非常にうまく機能します。モバイル開発とは異なり、必要に応じてすぐに変更が有効になるため (ビルドとテスト以外にデプロイする時間がない)、プッシュしたコードにバグがないかどうかをすばやくテストし、すばやく変更を加えることができます。したがって、このワークフローはサーバー側の開発に非常に適しています。ただし、このワークフローを使用したモバイル開発では問題に直面しています。
gitflow ワークフローには、開発、ステージング、マスターという 3 つの永続的なブランチがあります。マスター ブランチのコードは Play ストア アプリに送られ、チーム メンバーのみが利用できるステージング用の別のクローズド ベータ版 Google Play ストア アプリがあり、crashlytics ベータ版を使用して、最新の開発ブランチ コードをチームの開発者のみに配布しています。誰かが新機能の作業を開始するたびに、その人は master から分岐した機能ブランチを作成し (以前は開発から分岐していました)、機能の準備が整ったら、開発へのプル リクエストを作成します。毎日、プル リクエストを確認し、問題のないものは開発にマージします。
現在、このワークフローで直面している 2 つの大きな問題があります。1 つは、ある機能を開発にマージした後、そこに多くのバグがあることがわかったとします。これ以上プッシュすることはできません。そのコードはすでに開発とマージされているため、開発サイクル全体が行き詰っています。これが、開発ではなくマスターからの機能ブランチのフォークを開始した理由です。少なくとも個々の機能ブランチには完全に機能するコードがあるためです。1 つの方法は、各機能をチーム メンバーに個別に配布してテストし、その後で開発にマージすることですが、非常に面倒です。では、この問題は別のワークフローで解決できますか?
もう 1 つの問題は、コードの競合です。すべてのフィーチャー ブランチのベース コードはマスター ブランチからのものであり、開発とマージする必要があるため、最近では多くの競合が発生しています。開発からフォークしていた以前は、開発ブランチを人々が取り組んでいる機能ブランチと定期的にマージしていたので、競合はありませんでしたが、もうそれはできません。そこで、競合を修正するために、フィーチャー ブランチから別の一時的なブランチを作成し、開発コードをマージして競合を修正し、それをプル リクエストとして配置しますが、これも少し面倒です。
これはすべて、モバイル開発に適していない gitflow ワークフローの問題のようです。人々が採用しているモバイル開発のより良いワークフロー、またはこれらの問題を解決するために従うことができるいくつかのプラクティスはありますか?