分岐モデルには、Vincent Driessen による成功した Git 分岐モデルを使用しています。すべて問題ありませんが、特定の問題が持ち上がったことは実際には見られませんでした。
私が理解したことから、新しい機能が必要な場合は、 のブランチをdevelopment作成して、新しいfeatureブランチを作成します。これに取り組み、完了したら、このブランチをブランチにマージしますdevelopment。
開発者が機能を作成し、その機能を にマージしてdevelopment、機能コードにいくつかのバグがあることが判明した場合はどうなるでしょうか。これはどこで修正する必要がありますか? 開発から新しいfix/bugfixブランチを開始し、そこでコードを修正する必要がありますか? 別の方法が見えません。
これについてどうすればいいですか？
ありがとう
モデルは単なるモデルであることを忘れないでください。一連のルールにやみくもに従うのではなく、より効率的な構造を提供することです。つまり、すべての状況で機能するとは限らないため、自由に微調整して、自分の状況で何が機能するかを理解する必要があります。
この状況では、次の選択肢があると思います。
どちらを選択するかは、次のような要因によって異なります。
機能ブランチとバグ修正ブランチの違いは、Git の観点からは重要ではありません。これらのラベルを内部文書またはその他の監査目的 (たとえば、外部ユーザーに表示されるものを追跡するため) に使用する場合にのみ問題になります。
バグ修正が非常に迅速に行われると考えていても、開発ブランチから直接作業する誘惑に抵抗してください。見た目ほど単純なことはありません。何か問題が発生した場合、後で頭痛の種になります。
選択内容の大まかな視覚的表現:
バグを導入したコミットを見つけて、そこに根ざした新しいブランチを作成するのはどうですか? このアプローチでは:
そのフィーチャー ブランチがパブリック ブランチである場合 (つまり、複製された/他のユーザーが使用するリモート リポジトリにプッシュされた場合)、新しいブランチを作成し、上記の修正ブランチでデバッグを分離することをお勧めします。(' ' ブランチの上に
' ' ブランチをリベースしようとする代わりに)。featuredevelop
途中のデバッグ コミットをブランチに直接記録するのではなく、ブランチ マージdevelopによって最初に導入されたバグを修正する結果のコミットのみを記録するという考えが残っています。feature
ブランチを作成して（または古いマージされたfeatureブランチを使用して）、そこで修正するだけです。
古いブランチの使用/新しいブランチの作成はまったく同じです---マージ後にどちらがどちらであるかを指定することはできません。