Gitブランチモデルでのマスターブランチの使用
私は、開発ブランチとマスターブランチ（機能が最初に開発にマージされる）を持つブランチモデルを見てきました。マスターブランチは常に完全に開発の履歴の一部であり、ビルドの実行とすべてのテストに合格すると早送りされます。そして、masterブランチに、develop、release、またはhotfixブランチからの実際のマージコミットが含まれる他の例を見ました（そのため、早送りはもはや不可能です）。後者はgitflowの場合だと思います。
各アプローチの利点/欠点/トレードオフは何ですか？最初のアプローチにより、本番環境に移行したすべてのコードが開発ブランチにも確実に含まれるようになります。しかし、ホットフィックスがどのように処理されるかは不明です。
Gitflowワークフロー では、ホットフィックスはマスターから作成されたブランチであり、最終的にマスターと開発でマージされます。
「マスターに直接コミットしないでください」の背後にある一般的な（そしてよく知られた）アイデアは、本番環境に完全に安全にデプロイできるコードの状態をマスターに含めることです。
ただし、他の手段を提供できます。 Githubの場合 、マスターは、機能が本番環境に導入されたときに知る追跡ツールとしても機能します。別のブランチでコミットしてからマスターを早送りすると、マージコミットが失われ、さらに拡張すると、マスタータイムラインに多数の小さなコミットが配置され、機能全体を元に戻すことができなくなります。以前のマージを元に戻すだけです。
このアプローチのもう1つの問題は、いつリリース/デプロイできるかを知ることです。全員がマスターにコミットする場合は、すべての開発を同期して、コードの一貫性のある状態にする必要があります。明確な範囲のモノリシックリリースの場合は問題ありませんが、私の場合、統合開発者として機能が行き来し、「すべての機能が実行された」時点が1つになることはありません。
ただし、マスターでコミットしないことは、ブランチマスターと開発者がいることを意味しません。 Githubプレゼンテーションで指摘されているように、 機能ブランチワークフロー を実行すると、マスターでのみ作業でき、各機能のブランチを作成し、それらをマスターに（早送りせずに）マージして戻します終わり。
私の控えめな意見では、Git Flow（マスター/開発+機能/ホットフィックス/リリースブランチ）は、いつリリースする必要があるか（各機能が完了したときではなく）本当にわからない場合に適しています。多くの場合、最後のリリースが修正プログラムです。 gitflowチャートは複雑にすることができますが、多くの場合、機能分岐ワークフローは読みやすくなります。 「ノイズ」は、数分後に削除されるブランチでのリリース/修正プログラムのコミットが原因であることがよくあります。
Gitflowの例
機能分岐ワークフローのグラフの例
