GitHubフローでは、機能ブランチを別の機能ブランチに基づいてもかまいませんか？

私たちはプロジェクトでGitHub Flowを使用し、ほとんどの場合、masterから新しい機能ブランチを開き、そこで作業を行い、PRを開き、コードを確認してmasterにマージします。

しかし、私の現在の仕事はで取り組んでいる別の問題に依存していfeature-branch-Aます。他のブランチからブランチを作成するのはコーシャーですか、それともGitHub Flowの精神に反するものですか？

別の方法は、私のブランチをマスターに基づいて、feature-branch-A（頻繁に）変更をマージすることです。

GitHubフローではどのオプションが推奨されますか？

機能分岐から分岐するときに従うワークフローは次のとおりです。

1. feature-branch-Bから作成feature-branch-A
2. に取り組む feature-branch-B
3. より多くのコミットが追加されている場合はfeature-branch-A分岐後、リベースfeature-branch-Bにfeature-branch-A
4. 作業を終了しfeature-branch-B、feature-branch-Aがにマージされるまで待ちmasterます。
5. 後feature-branch-Aにマージされmasterリベース、feature-branch-B上にmaster
6. にfeature-branch-B統合master

上記のワークフローに従うと、マージmaster後feature-branch-Aに分岐したように見えます。feature-branch-Aが統合されるまで作業を開始するまで待つ必要はありませんfeature-branch-B。それでも、複雑なツリーがなくても、クリーンな履歴を取得できます。

別の機能で機能を作成する場合、これはまったく問題ないと思います。

しかし、頻繁にそれをしないでください。これを作成した1人の開発者と、1、2週間でマージのために10個のPRを投げるのを見ます。他のメンバーはレビューのために完全に疲れ果て、マージも困難でした。gitで木を作らないでください。これは、エラーを見つけるための二分法に役立ちます。

git-flowが対処することを意図した重要なことは、特定のブランチの役割、およびブランチの分岐元とマージ先について推論する能力でした。

理想的には、すべてのブランチはマージ元のコードラインにマージされます。これは通常、メインラインからのマージです（git-flowではdev）。機能ブランチはdevから分岐してマージし、リリースブランチはdevからブランチしてマージします（への追加マージを使用master）。マスターからのブランチとマージのホットフィックス（devへの追加のマージ）。

各コードラインは、その親から分岐し、親にマージします。コードラインは、必要に応じて、いつでも他のコードラインからコードを取り込むことができます。

機能ブランチからのブランチが「その機能ブランチの問題を修正するこの方法を探求したい」場合-まったく問題ありません。機能ブランチから分岐し、一部のコードをコミットして、機能ブランチにマージします（または破棄します）。

1. 機能から分岐
2. アイデアを探る
3. 機能にマージ

ただし、避けたいのは次のようなものです。

1. 必須機能からの分岐
2. コードに取り組む
3. required-featureが完了したら、devからマージします
4. 機能ブランチの機能（および追加のコミット）を検証する
5. 開発者にマージ

理由は、開始と終了が一致しないためです-これが何であったかを理解するのが少し難しくなります。不可能ではありませんが、誰かがその役割を理解するのに少し時間がかかるだけです。

ただし、これがdevにまだないコードに依存する新しい機能である場合、フローは次のようになります。

1. 開発者からの分岐
2. required-featureからマージ
3. コードに取り組む
4. required-featureが完了したら、devからマージします
5. 機能ブランチの機能（および追加のコミット）を検証する
6. 開発者にマージ

これはdevからのブランチで始まり、devへのマージで終わることに注意してください。

とはいえ、おそらく最善の方法は、ある機能から別の機能へのマージを避けることです。機能を分岐させ、必要な準備をして...待ってください。

1. 開発者からの分岐
2. コードに取り組む
3. required-featureが完了したら、devからマージします
4. 機能ブランチの機能（および追加のコミット）を検証する
5. 開発者にマージ

これにより、最も安定したブランチとコードのセットが提供されます。

将来の作業のために考慮すべきことは、実装コードが完全ではない場合でも、他の機能との相互運用性に必要なインターフェースを公開する機能を持つことです。これはdevにマージされ、その後、required-featureは、future-featureと同様に、これらのインターフェースで機能します。これにより、必要な機能がdevにマージされるのを待たなければならない場合よりも、将来の機能をさらに進めることができます（インターフェイスに対するコーディング、インターフェイスを実装するスタブに対するテスト）。

機能ブランチは通常、トランク（開発/マスター）よりも安定性が低いと見なされます。そのため、作業ブランチをベースにすると、通常よりも多くの根本的な変更を受ける可能性があります。

また、ブランチがプッシュされた場合、通常は眉をひそめますが、機能ブランチを親ブランチにリベースして、より良い履歴を取得することは珍しくありませんが、追加のブランチがハングしている場合は非常に複雑になります基本的に、親ブランチの所有者に新しい制限を作成し、自分自身の頭痛の種を作成しています。

とはいえ、それに対する厳密なルールはありません。結局のところ、これらは単なるパターンであり、ベストプラクティスです。

編集：質問の一部を逃しました。機能ブランチを独自のものにマージしますが、これは上記の問題を実際に回避するものではなく、実際にはさらに複雑な履歴を作成する可能性があります。

したがって、もし私があなたの靴を履いていて、機能aが完了するまで仕事を延期できるか、または何か他のことを最初にやるなら、私はそれをするでしょう。