6

私はブランチに取り組んできましたnew_feature：

A -- B -- C -- D    master
      \    \
       \    1 -- 2 -- 3  new_feature
        \
         E -- F -- G  port

port私たちのコードベースには、別の開発者が私たちの製品を別のRDBMSに移植した古いブランチもあります。portにマージして戻す準備はまだできていませんmaster。

new_feature最近、で仕事をすることが必要になりましたport。そこで、これら2つを新しいブランチにマージし、そこでport/new_featureいくつかのコミット（I、J）を行って、それを機能させました。

A -- B -- C -- D    master
      \    \
       \    1 -- 2 -- 3 -- I* -- J* -- K new_feature
        \              \
         E -- F -- G -- H -- I -- J -- K*  port/new_feature
                  port

私はIとJを（I *、J *として）チェリーピックしました。new_featureなぜなら、それらには私も入れたかった重要なリファクタリングが含まれていたからnew_featureです。また、 （K *）new_featureに引き継ぐ必要がある新しいコミット（K）を作成しています。port/new_feature

今後、同期を維持するための最良の計画は何new_featureですかport/new_feature（ただし、新しい変更に関してのみ）？チェリーピッキングのコミットを一方から他方に（およびその逆に）維持する必要がありますか？または、マージしてこれを行う便利な方法はありますか？

4

1 に答える 1

1

さくらんぼ狩りは次の理由で危険です：

  • I-J-K重複コミット（Gitは...の上に再適用しようとするため、次のマージは複雑になりますI-J-K）。
    一方のブランチをもう一方のブランチの上にリベースする場合はそうではありませんが（「Gitチェリーピックとデータモデルの整合性」を参照）、それはあなたの場合には不可能です。

  • 機能依存性（「gitで特定のコミットをマージする方法」を参照）が、あなたの場合は問題ではないIと思います。Jに依存せず H、に安全に適用できます3。

ポートと新機能を一緒にマージするつもりがない場合は、チェリーピッキングが便利です。
その場合は、さくらんぼ狩りを続けてください。

于 2012-11-21T07:58:12.167 に答える