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

Question

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

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

もう1つの方法は、ブランチをマスターにして、feature-branch-Aからの変更を（頻繁に）マージすることです。

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

Answer 1

これは、機能ブランチからブランチするときにたどるワークフローです。

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にマージ

上記のワークフローに従うと、feature-branch-Aがマージされた後、masterから分岐したように見えます。 feature-branch-Aがマージされてfeature-branch-Bの作業を開始するまで待つ必要はありません。しかし、複雑な木がなくても、きれいな歴史を手に入れることができます。

Answer 2

別のフィーチャーでフィーチャーを作成する場合、これは完全に問題ないと思います。

しかし、それを頻繁に行わないでください。これを作った開発者1人と1週間か2週間、彼はマージのために10のPRを投げました。それは他のメンバーがレビューのために完全に疲れきっており、マージするのも困難でした。 gitでツリーを作成しないでください。これは、エラーを見つけるためのbisectに役立ちます。

Answer 3

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

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

各コードラインは、その親から分岐し、その親にマージされます。コードラインmay必要な場合はいつでも他のコードラインからコードを取得します。

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

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

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

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

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

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

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

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

そうは言っても、おそらく最善の方法は、ある機能から別の機能へのマージを回避することです。機能を分岐し、必要な準備をすべて行い、待機します。

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

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

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

Answer 4

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

また、ブランチがプッシュされている場合は通常は嫌われますが、機能ブランチを親ブランチにリベースしてより良い履歴を取得することは珍しいことではありませんが、他のブランチがぶら下がっている場合は、さらに複雑になります。本質的に、親ブランチの所有者に新しい制限を課すだけでなく、自分にとって頭痛の種になる可能性もあります。

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

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

したがって、私があなたの立場にいて、機能aが完了するまで作業を延期できた場合、または最初に何か他のことを実行できた場合、私はそれを行います。