33

私はしばらくの間 git flow を使用しています。開発ブランチで見つかった問題やバグを修正するためのブランチ モデルを探していました。ホットフィックスを使用できることはわかっていますが、これはマスター ブランチ、またはプロダクションの迅速なバグ修正のためのものです。

開発時のバグ修正は機能ではありません。いつでも git フローを再初期化し、デフォルトのプレフィックス ブランチを bug/. ただし、新しい機能も開始する必要がある場合は、再初期化する必要がありました。これは良い習慣ですか、それともこれを処理するためのテクニックはありますか?

4

3 に答える 3

24

適用する必要がある修正が 1 つのコミット修正だけである場合は、ブランチを作成せずに開発で実行します。複数のコミットが含まれる場合は、git flow featureコマンドを使用するだけです。現在、ソフトウェアはgit merge -ff1 つのコミットのみで機能ブランチを終了すると、ログでは開発時のコミットと同じように表示されます。

この機能がバグ修正であることをログに示したい場合は、ブランチに「bugfix-missing-parameter」または「issue-34-not-reading-file-properly」のような名前を付けることができます

機能という言葉が「修正」ではなく「何か新しいもの」を暗示していることはわかりますが、それは単なる言葉です。修正のために新しいコマンドを作成する必要がある場合、コードはのコードとまったく同じに見えるgit flow featureので、それには何の利点もありません。

2015 年 11 月 19 日更新

バージョン 1.9.0 以降、gitflow AVH Edition にはバグ修正コマンドがあります。これは feature と同じですが、ブランチには feature ではなく bugfix がプレフィックスとして付けられています。

于 2012-06-26T12:40:19.537 に答える
13

(on ) とはdevelopment対照的に、ブランチのバグを修正するという考え方は次のとおりです。git flow hotfixmaster

  • 通常、開発時にバグを修正しますHEAD（他のコミットによって導入された問題を修正する別のコミットです）
  • 専用ブランチで master の特定のバージョン/タグ (「productionブランチ」) にホットフィックスを実行し、そのホットフィックスをマージするかしないか (ホットフィックスが特定のバージョンに非常に固有であり、もはや関連性がない場合)後続のリリースでは、マージして戻すことはまったくありません)

したがって、専用のブランチ / " " 操作は必要ないと思います。適切に識別されたコミットを作成し、ブランチgit flowの上にプッシュするだけです。development

于 2012-06-26T07:40:52.227 に答える