Scott Chacon によって説明された「github フロー」ワークフローがとても気に入っています: http://scottchacon.com/2011/08/31/github-flow.html
彼は、Github が Vincent Driessen ( http://nvie.com/posts/a-successful-git-branching-model/ ) によって説明された git フロー ワークフローを使用しない理由を説明しており、同じ理由で使用していません。最も重要な理由は、プルリクエストではうまく機能せず、「ソフトウェア製品の公式にリリースされたバージョン」を持っていなくても Web サイトを継続的に改善する Web サイト開発にはうまく適合しないことです。
私たちは小さなチームで大規模なオンライン コミュニティを開発しており、多くの古いレガシー コード (一部のコードは 10 年以上前のもの) があり、テスト カバレッジが不十分です。私たちは github と同様のワークフローを使用しています。現在、開発にはフィーチャー ブランチを使用し、プル リクエストを使用してそれらをマスター ブランチに統合し、ピア レビューを行い、フィードバックを求めます。フィーチャーが完成し、他の人によって承認されると、それはマスターに統合されました。週に数回、テスターとベータ ユーザーが使用するステージング環境にマスターをプッシュします。マスター ブランチを 2 週間ごとに公開するように努めているため、マージされるすべての機能ブランチは十分にテストする必要があり、「よりリスクの高い機能ブランチ」は、公開が完了するまでここ数日はマージされません。
これは完全なワークフローではありません。マスターへの「危険な機能」のマージが再び開始されると、マスターを使用してホットフィックスを公開することができなくなるためです。
Github はデプロイに継続的デリバリーを使用していますが、これは私たちのオプションではありません。公開する前に機能をテストする人が必要です。
プル リクエストは 1 つのブランチにのみマージできます。したがって、マスターである長期実行ブランチが 1 つだけの github での単純なワークフローです。おそらく、2 週間ごとにリリースするのではなく、マスターにマージされたときにプル リクエストをリリースするべきではないでしょうか? しかし、そのようにテストするのは難しいです。フィーチャー ブランチがマージされる前に、機能ブランチでユニット テストを実行できます。また、ベータ テスターのためにブランチをステージングにデプロイすることもできます。データベースは手動で変更されます (自動的に行うことはできません。ベータ テスター用のステージング サーバーが運用データベースを使用しているため、リスクが高すぎます)。そのため、管理者がこれを行うまで待つ必要があります。さらに大きな問題は、機能ブランチのみをベータ ユーザーにリリースした場合、それらは統合されず、新しい機能が表示されることです。機能はおそらく 1 日に何度も削除されます。機能ブランチがマスターにマージされたばかりのときに、統合テストを実行できない、またはリリース直前に非常に遅く実行したことは言うまでもありません...
一方、git-flow で説明されているように、develop と master のような 2 つの実行時間の長いブランチを使用すると、ホットフィックスの問題を解決できます。最近の変更をマスターにマージするためのリリース ブランチですが、プル リクエスト ワークフローを使用して開発するために変更をマージすることはできません。
github フローの記事 (#6 – レビュー後すぐにデプロイ) でわかるように、github エンジニアは本番環境だけでなく、ステージング環境にもデプロイできます。そして、エンジニアだけでなく、サポートやデザイナーもそれを行うことができます。しかし、統合ブランチが 1 つだけの場合、どのように機能するのでしょうか? 最後のプル リクエストが数時間または数分で本番環境に移行する場合は、ステージング環境は必要ありません。機能ブランチをステージングにデプロイしているように見えることもありますが、これは理にかなっていますが、統合されていないため、上記で説明したことが起こります。機能をデプロイする前にマスターからの変更をマージしたとしても、ステージング環境で機能が出入りすることがわかります。 -ステージングへの分岐 (これは良い考えだと思いますか?)。それとも、複数のステージング環境を持つことに意味があるのでしょうか? すべての機能ブランチに 1 つですか? しかし、この方法でも、継続的インテグレーションの利点が失われます。前述のとおり、ベータ テスト環境でこれを行うことはできないと思います。
git フローと github フローの両方のワークフローに問題が見られます。私は github フローの方が好きですが、十分なテスト カバレッジがなく、さらに人によるテストが必要な場合は難しいようです。
では、人々 (qa およびベータテスター) によるさらに多くのテストが必要な場合、機能ブランチを統合してテストするにはどうすればよいでしょうか?