git pull --rebaseデフォルトで を使用する人もいれば、絶対に使用しないと主張する人もいます。マージとリベースの違いは理解していると思いますが、これを のコンテキストで説明しようとしていますgit pull。マージ コミット メッセージをたくさん表示したくないだけなのでしょうか、それとも他の問題があるのでしょうか。
ベストアンサー1
git pull --rebase実際に何を意味するのかという点については、時々見失われてしまうことがあるため、別の視点を提供したいと思います。
Subversion (または CVS) を使用したことがある場合は、 の動作に慣れているかもしれませんsvn update。コミットする変更があり、上流で変更が行われたためにコミットが失敗した場合は、 になりますsvn update。Subversion は上流の変更をマージして処理を進めますが、競合が発生する可能性があります。
Subversion が行ったことは、基本的には でしたgit pull --rebase。ローカルの変更を新しいバージョンに相対的に再定式化する操作は、その「リベース」部分です。svn diff失敗したコミット試行の前に を実行して、その結果の diff をその後の出力と比較するとsvn diff、2 つの diff の違いがリベース操作によって行われたものになります。
この場合の Git と Subversion の主な違いは、Subversion では「自分の」変更は作業コピー内のコミットされていない変更としてのみ存在するのに対し、Git では実際のコミットがローカルに存在することです。言い換えると、Git では履歴がフォークされており、自分の履歴と上流の履歴は分岐していますが、共通の祖先が存在します。
私の意見では、ローカル ブランチがアップストリーム ブランチを単に反映し、それに対して継続的な開発を行う通常のケースでは、正しいことは常に です。--rebaseなぜなら、それが意味的に実際に行っていることだからです。あなたと他の人は、ブランチの意図された線形履歴をハッキングしています。他の誰かが、あなたがプッシュしようとした少し前にプッシュしたという事実は無関係であり、そのようなタイミングの偶然のたびに履歴のマージが発生するのは逆効果のようです。
何らかの理由で何かをブランチにする必要性を感じた場合、それは別の問題だと私は思います。しかし、変更をマージの形式で表現したいという具体的かつ積極的な要望がない限り、デフォルトの動作は であるべきだと私は思いますgit pull --rebase。
プロジェクトの履歴を観察して理解する必要がある他の人のことも考慮してください。履歴に何百ものマージが散らばっていることを望みますか、それとも、意図的に異なる開発作業の実際のマージを表す、選ばれた少数のマージだけを望みますか?