☰

シンプルなブランチワークフローを維持しながら、変更をリモート追跡機能ブランチにプルする

tag-icon • tag-icon git version-control branch
シンプルなブランチワークフローを維持しながら、変更をリモート追跡機能ブランチにプルする

私たちは、マスター ブランチを持ち、機能ブランチで機能を開発している数人の開発者のチームです。リリース時に、マスターのリリース ブランチを分岐します。すべてのバグ修正はマスターで行われ、その後、関連するリリース ブランチにチェリーピックされます。

私たちは、各新機能ごとに、ロールバックして二分できるアトミックマージコミットを用意したいと考えています。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

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

リモート追跡ブランチを破損させず、クリーンな履歴と他の機能開発者の作業コピーを台無しにすることなく、これを行う方法はありますか?

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

答え1

バグを機能ブランチにチェリーピックして、gitが自動的に解決してくれるでしょうか？

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

チェリーピッキング時に競合を解決する場合は、PR をマージする直前に、マスターの上にリベースするときにコミットを手動で削除できます (競合を解決するコミット メッセージにタグ付けしたり、リマインダーを書き込んだりできます)。

しかし、私としては、ホットフィックスが利用可能になったら、機能ブランチをマスターの上にリベースすると思います。これは、マスターからの変更をプルするのと同じです (最近マージされた他の機能ブランチを含む)。したがって、ブランチが古くなることを心配する必要はありません。マージされたホットフィックスを削除するか、頻繁にリベースするかなど、チームが何を処理したいかによって異なります。

答え2

バグ修正が本当に必要な場合は、バグ修正ブランチをマージしてください。bisect/rollback/その他についての話はFUDでした。私の経験では、bisectは複雑なマージ履歴をうまく処理します。その投稿で提案されたモデルは人工的な問題（あなたが質問しているような問題）を生み出し、文字通りその唯一の利点はよりクリーンなことです。見ている履歴。リベースしないことの利点に気づくまで、このモデルを数年間使用していました。自分の履歴をクリーンアップする必要があるとき（コミットの圧縮、コミット メッセージの変更など）にのみリベースしますが、これは下流の誰にも影響しません（ブランチで単独で作業している場合など）。

関連情報