Git チェリーピックとマージワークフロー 質問する

rebase（およびcherry-pick）とにはそれぞれmerge長所と短所があります。ここではどちらを主張するかmergeですが、両方を理解する価値はあります。（別の、よく議論された議論については、こちらをご覧ください。答えが好まれるケースを列挙しますrebase。

mergeいくつかの理由からcherry-pick、 がよりも好まれます。rebase

1. 堅牢性。コミットの SHA1 識別子は、コミット自体だけでなく、その前のすべてのコミットとの関係でもコミットを識別します。これにより、特定の SHA1 でのリポジトリの状態がすべてのクローン間で同一であることが保証されます。誰かが同じ変更を行ったように見えても、実際にはリポジトリを破損または乗っ取っている可能性は (理論上) ありません。個々の変更をチェリーピックすることはできますが、それらは同じである可能性は高いですが、保証はありません。(軽微な二次的な問題として、誰かが同じコミットを再度チェリーピックした場合、新しくチェリーピックされたコミットは余分なスペースを占有します。作業コピーが最終的に同一になったとしても、それらは両方とも履歴に存在するためです。)
2. 使いやすさmerge。人々はワークフローをかなり簡単に理解する傾向があります。rebaseより高度であると見なされる傾向があります。両方を理解するのが最善ですが、バージョン管理の専門家になりたくない人 (私の経験では、自分の仕事は非常に上手だが余分な時間を費やしたくない同僚がたくさんいます) は、マージする方が簡単です。

マージの多いワークフローであってもrebase、cherry-pick特定のケースでは依然として役立ちます。

1. の欠点の 1 つは、merge履歴が乱雑になることです。rebaseは、他の人の変更を定期的にマージすると、長い一連のコミットが履歴に散らばってしまいます。 実際、これが私が使用している主な目的です。非常に注意したいのは、rebase他のリポジトリと共有しているコードを決して使用しないことです。 コミットすると、push他の誰かがその上にコミットしている可能性があり、リベースすると、最善の場合でも、上で説明したような重複が発生します。 最悪の場合、非常に混乱したリポジトリと、見つけるのに長い時間がかかる微妙なエラーが発生する可能性があります。
2. cherry-pick基本的に破棄することにしたトピック ブランチから、変更の小さなサブセットをサンプリングするのに便利ですが、いくつか役に立つ部分があることに気付きました。

1 つの変更よりも多くの変更をマージするほうがよいという点については、その方がずっと簡単だからです。変更セットが大量に発生すると、個々の変更セットのマージは非常に面倒になります。git (および Mercurial、Bazaar) のマージ解決は非常に優れています。ほとんどの場合、長いブランチをマージしても大きな問題に遭遇することはありません。私は通常、すべてを一度にマージし、多数の競合が発生した場合のみ、バックアップしてマージを部分的に再実行します。その場合でも、大きな塊で行います。非常に現実的な例として、3 か月分の変更をマージし、250,000 行のコードベースで約 9,000 件の競合が発生した同僚がいました。これを修正するために行ったのは、一度に 1 か月分のマージを行うことです。競合は直線的に増加するわけではなく、断片的に行うことで、競合は9,000 件よりはるかに少なくなります。それでもまだ大変な作業でしたが、一度に 1 つのコミットを実行するほどではありませんでした。