私たちは git-flow を使用してホットフィックスと機能を処理し、develop ブランチと master ブランチ (本番用) を使用しています。
ステージング ブランチをミックスに追加して、git-flow の有用性を維持しながら、develop から production に向かう途中の作業を検証できるようにする最も簡単な方法は何ですか?
私たちは git-flow を使用してホットフィックスと機能を処理し、develop ブランチと master ブランチ (本番用) を使用しています。
ステージング ブランチをミックスに追加して、git-flow の有用性を維持しながら、develop から production に向かう途中の作業を検証できるようにする最も簡単な方法は何ですか?
私は git flow を使い始めたばかりですが、最も簡単な方法は、次のリリースをdev
ブランチとして設定し、本番リリースをstage
ブランチとして設定してから、たとえば手動でmaster
ブランチ (実際の本番) とマージすることです。
したがって、バージョン 1.2.0 をリリースしstage
てからリリースにバグが見つかった場合 (コア CMS、機能 1、機能 3、機能 4 などの 4 つのホットフィックス)、いつでもパッチを適用できるため、たとえばバージョン 1.2.4 で終わる可能性があります。そして最後にそれを本番環境にマージします。
更新: このシナリオは、ロールバック メカニズムがないことを前提としているため、修正、リリース機能などのために常にコミットを追加します。ロールバック メカニズムがあれば、本番環境でのバグについて心配する必要はありません。エラーが見つかったら、ロールバックを使用して以前の作業バージョンをセットアップします。例: version にバグが見つかった場合は、 version1.2.3
に戻り1.2.2
ます。バグを修正し、テストしてdev
からstage
、バージョンとして本番環境にプッシュし1.2.4
ます。1.2.2
したがって、生産はまっすぐからにジャンプします1.2.4
。