gitflowを使用してホットフィックスを機能ブランチに組み込むにはどうすればよいですか?


10

プロジェクトでgitflowの使用を開始しましたが、未処理の機能ブランチと新しく作成した修正プログラムがあります。gitflowワークフローに従って、ホットフィックスはマスターブランチと開発ブランチの両方に適用されますが、現存する機能ブランチについては何も言われておらず、行われていません。

それでも、修正プログラムの変更を機能ブランチに組み込みたいと思います。これは、できる限り3つのオプションを残します。

  1. 変更を組み込まないでください。機能ブランチに変更が必要な場合、それは機能ブランチの一部であるはずです。
  2. マージ開発機能ブランチに戻ります。これはgitflowワークフローに最もよく従うようですが、順不同のコミットを引き起こします。
  3. 機能ブランチを開発にリベースします。これはコミットの順序を保持しますが、リベースは一般的なgitflowワークフローには完全に存在しないようです。

ここでのベストプラクティスは何ですか?

git  gitflow 

機能ブランチは一般的に非常に短命であると考えられおり、変更ブランチにマージすることは一種のSCMの匂いです。機能ブランチを完成(または安定化)させて元に戻すことは不可能ですか?
アーロンノート2012

2
@Aaronaught機能はまだ完了していない/どこにも行かない場合があります。基本的な状況は、開発に数日かかる機能が、本番データに影響を与える可能性のあるバグを発見したことです。テストが作成され、ホットフィックスがマスター/本番に適用されましたが、未完成の機能はまだバグによって壊れています。半分完成した機能を開発メインラインにマージすることを提案していますか?機能がうまく機能しない場合はどうなりますか?

回答:


11

機能ブランチを開発にリベースして最新のホットフィックスを取得することに問題はありません。実際、開発に対して機能ブランチを頻繁にリベースすると、ブランチを「最新の状態」に保つことができるため、その段階に到達したときにマージがはるかに簡単になるため、役立ちます。


ええ:機能のリベースを追加したgitflow 0.2のアナウンスなど、状況証拠をさらに調べてみると、通常のgit rebaseワークフローがgitflowワークフローでもあることがわかります。

2
面白い。私がGitflowの専門家であるとは言えませんが、私の理解では、ホットフィックスはブランチではなくマスターに対する単一のコミットであり、開発のためにそれらを選んだだけです。読んで、私はそれについて完全に間違っていたと思いました。
jb510 2014
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.