とrebase（およびcherry-pick）にmergeは、それぞれ長所と短所があります。私はmergeここで主張しますが、両方を理解する価値があります。（優先されるケースを列挙した、代替のよく議論された答えをここで探してくださいrebase。）
merge好ましいcherry-pickとrebaseの理由のカップルのため。
- 堅牢性。コミットのSHA1識別子は、それ自体だけでなく、それに先行する他のすべてのコミットとの関連でもそれを識別します。これにより、特定のSHA1でのリポジトリの状態がすべてのクローンで同一であることが保証されます。（理論的には）誰かが同じ変更のように見えることをした可能性はありませんが、実際にはリポジトリが破損またはハイジャックされています。個々の変更をチェリーピックすることができ、それらは同じである可能性がありますが、保証はありません。（マイナーな二次的な問題として、作業コピーが同一になったとしても、両方が履歴に存在するため、同じコミットで他の誰かが再びチェリーピックすると、新しいチェリーピックコミットは余分なスペースを消費します。）
- 使いやすさ。
mergeワークフローはかなり簡単に理解できる傾向があります。 rebaseより高度であると考えられる傾向があります。両方を理解することをお勧めしますが、バージョン管理の専門家になりたくない人（私の経験では、自分の仕事は得意ですが、余分な時間を費やしたくない同僚が多くいます）。時間はちょうど融合します。
マージが多いワークフローrebaseでcherry-pickも、特定の場合に役立ちます。
- への1つの欠点
mergeは乱雑な歴史です。 rebase他の変更に定期的にマージした場合のように、長い一連のコミットが履歴に散らばることを防ぎます。私が実際に使用するのは、これが実際の主な目的です。あなたがなりたいものに非常に慎重に、決してにされていないrebase、あなたが他のリポジトリと共有していることをコード。コミットがpush編集されると、他の誰かがその上でコミットした可能性があり、リベースはせいぜい上記のような種類の重複を引き起こします。最悪の場合、リポジトリが非常に混乱し、微妙なエラーが発生して、フェレットアウトに長い時間がかかります。
cherry-pick 基本的に破棄することに決めたトピックブランチから変更の小さなサブセットをサンプリングするのに便利ですが、いくつかの便利な部分があることに気づきました。
多くの変更を1つよりもマージすることを好む場合については、それは非常に単純です。多数のチェンジセットを作成し始めたら、個々のチェンジセットをマージするのは非常に退屈な作業になる可能性があります。git（およびMercurial、Bazaar）のマージ解決は非常に優れています。ほとんどの場合、長いブランチでさえマージする大きな問題に遭遇することはありません。通常、すべてを一度にマージします。多数の競合が発生した場合にのみ、バックアップを取り、マージ断片を再実行します。それでも私は大きな塊でそれをします。非常に現実的な例として、3か月分の変更をマージする同僚がいて、250000行のコードベースで9000件の競合が発生しました。修正するために行ったのは、一度に1か月分のマージを実行することです。競合は直線的には増加せず、バラバラに実行すると結果が大きくなります。9000未満の競合。それはまだ多くの作業でしたが、一度に1つのコミットを実行することほどではありませんでした。