シンプルな分岐ワークフローを維持しながら、変更をリモートトラッキング機能分岐に取り込む

私たちはmasterブランチを持ち、featureブランチで機能を開発する数人の開発者のチームです。リリース時にマスターのブランチをリリースします。すべてのバグ修正はmasterで行われ、関連するリリースブランチに厳選されます。

https://gist.github.com/jbenet/ee6c9ac48068889b0912で説明されているように、ロールバックして二分することができる各新機能のアトミックマージコミットが必要です。このような歴史を私たちに与えてくれるはずです。

* aa55ffe -  (HEAD, master) D
* 88425f8 -  C
*   7bc519f -  Merge branch 'feature-X' into master
|\
| * 9364e61 -  feature-X: 2
| * bc76674 -  feature-X: 1
|/
* 88425f8 -  B
*   7bc519f -  Merge branch 'feature-Y' into master
|\
| * 0e0deea -  feature-Y: 4
| * 11079b5 -  feature-Y: 3
| * 9364e61 -  feature-Y: 2
| * bc76674 -  feature-Y: 1
|/
* c765ae3 -  A

私たちの問題は、同じ機能で複数の開発者が機能ブランチのリモートバージョンを追跡するときに発生します。一部の開発者はその機能に取り組んでいますが、masterでの機能開発中にバグ修正が行われる可能性があるためです。これらのバグ修正を機能ブランチに含める必要があります（つまり、バグが修正されたマスターで新しい状態の機能ブランチをリベースします）。

これを行う方法には、リモート追跡ブランチの破損を含まないため、クリーンな履歴と他の機能開発者の作業コピーが台無しになりませんか？

Fxバグを機能ブランチにチェリーピックし、機能ベースブランチの新しいリベースバージョンをマスターにマージする直前にリモートトラッキングブランチを孤立させる最終リベース後に、gitに自動的に解決させることができますか？

バグを機能ブランチにチェリーピックして、gitに自動的に解決させることができますか？

修正により競合が発生しない場合、これは機能します。git clone https://gist.github.com/jbenet/7959265、履歴を参照して、そこに貼り付けたreflogを読んでください。

チェリーピッキングで競合を解決する場合、PRをマージする直前に、マスターの上にリベースするときにコミットを手動で削除できます（競合を解決するコミットメッセージにタグを付ける/リマインダーを書き込むことができます）。

しかし、IMOでは、修正プログラムが利用可能になったときに、機能ブランチをマスターの上にリベースしました。これは、マスターから変更を取り込むことと同じです（最近マージされた他の機能ブランチを含む）。したがって、ブランチが古くなっていることを心配する必要はありません。チームが何を処理するかによって異なります。マージされた修正プログラムを削除するか、頻繁にリベースします。

機能ブランチで本当にバグ修正が必要な場合は、バグ修正ブランチをマージします。bisect/ rollback / whatever FUDについての話です。私の経験では、bisectは複雑なマージ履歴をうまく処理します。その投稿で提案されたモデルは、人為的な問題（あなたが質問している問題など）を作成し、文字通り、その唯一の利点は、よりきれいな外観の履歴です。このモデルを数年間使用してから、リベースしないことの利点を実感しました。自分の履歴をクリーンアップする必要がある場合（スカッシュコミット、コミットメッセージの変更など）にリベースしますが、ダウンストリームの他の人には影響しません（ブランチソロで作業している場合など）。