しばらくgit flowを使用しています。開発ブランチで見つかった問題とバグを修正するためのブランチモデルを探していました。私たちはホットフィックスを使用できることを知っていますが、それはマスターブランチ、またはプロダクションの迅速なバグ修正用です。
開発時のバグ修正は機能ではありません。私はいつでもgitフローを再初期化し、デフォルトのプレフィックスブランチをbug /に上書きできました。しかし、私も新機能を開始する必要がある場合は、再初期化する必要がありました。これは良い習慣ですか、これを処理するためのテクニックはありますか?
git-flow-avh
はあなたが欲しいものです
osx:の場合
brew uninstall git-flow #remove your current
brew install git-flow-avh #add the update
プロジェクトフォルダ内:
git init
Bugfix branches? [bugfix/]
これは標準のプロンプトではなかったでしょうgit-flow
git flow bugfix start <branch name>
適用する必要がある修正が1つのコミット修正である場合、ブランチを作成せずに開発でそれを実行します。複数のコミットが含まれる場合は、git flow feature
コマンドを使用するだけです。現在、ソフトウェアは、機能ブランチを1つのコミットのみで完了したときにgit merge -ff
を実行します。これは、ログでは、開発時のコミットと同じように見えます。
この機能がバグ修正であることをログで示したい場合は、「bugfix-missing-parameter」または「issue-34-not-reading-file-properly」のような名前をブランチに付けます。
Wordの機能が「修正」ではなく「何か新しいもの」を意味することがわかりますが、それは単なる単語です。修正のために新しいコマンドを作成する場合、コードはgit flow feature
のコードとまったく同じに見えるため、その利点はわかりません。
2015年11月19日更新
バージョン1.9.0以降、gitflow AVH Editionにはバグ修正コマンドがあります。これは機能と同じですが、ブランチは機能ではなく接頭辞がバグ修正です。
git flow hotfix
(development
上)ではなく、master
ブランチのバグを修正するという考えは、次のとおりです。
HEAD
(これは、他のコミットによって発生した問題を修正する別のコミットです)production
branch")に修正プログラムを実行し、その修正プログラムをマージするかしないか(修正プログラムが特定のバージョンに非常に固有である場合)後続のリリースでは関係なくなったため、マージすることはありません)したがって、専用のブランチ/ "git flow
"操作は必要ないと思います。明確に識別されたコミットを作成し、development
ブランチの上にプッシュするだけです。