私たちは git を使用するチームです。中央リポジトリ (単一のオリジン) を使用します(pushそしてpullカピストラーノはそれを使用してブランチ マスターをデプロイします)。
私たちは定期的にコミットとデプロイを行っています (1 日 10 ～ 20 回のデプロイ)。つまり、大量のマージ コミットがありgit blame、悪夢のようになっています。
git pull --rebaseこれを回避するために使用できるより単純な履歴を持つためにそれを読みました。マスターブランチで常にこれを行うのは良い考えですか?
もしそうなら、次の設定で設定することをお勧めします：
git config branch.master.rebase true
これに問題はありますか？
全く問題無い。実際、それが好ましいです。
99% の場合、変更をリベースする方がよいでしょう。そうでない場合、開発者はいつでもリベースを中止し、変更を手動でマージできます。
代替手段 (プルでのマージ) は、何の意味も持たない大量の小さなサイド コミットとマージを引き起こします。
一般に、ローカルの変更をマージする意味はあまりありません。これは、開発者が開始した正確なリビジョンに何か特別なことがあり、何らかの形で別のリビジョンにリベースすると、情報が失われることを意味します (おそらく、「ボブの機能の前にこれを開始しました。そうでない場合に備えて、それを伝えたいと思います。ボブとうまくやると、責められる」とか…）。これが実際に当てはまることはめったになく、クリーンで直線的なコミット履歴は追跡するのがはるかに簡単です。
デフォルトでプル リベースを作成することは問題ありません (必ずしも「良いアイデア」ではなく、必ずしも「悪いアイデア」でもありません)。実際には作業をリベースすることを覚えておく必要があります。ボブが変更する前にリポジトリにあったものにすべて依存する一連のコミットを作成した場合1、リベース (ボブの変更の上に) により、それらすべてのコミットを修正する必要が生じる可能性があります。最終的なマージ コミットのみを修正します。
私はこれを手動で行うことを好みます: run git fetch、git rebaseまたはgit merge状況に応じて、フェッチを行った後に発見できます。
git pull --rebaseただし、 （および/または設定）には利点がありbranch.master.rebase trueます。「リベースでプル」は非常にスマートで、リモートがリベースも行った場合を処理できるという点です。
1ここでの「ボブ」は、pushいわば、あなた自身の変更が「消化不良」になる原因となる何らかの変更を行った (そしてあなたを一歩踏み出した) 人を表します。
私の経験では、いつでもプル.リベースで問題ありません。マージの競合が発生したくない場合は、ローカル ブランチで作業できます。また、最新のコードで作業したい場合は、現在の作業がプッシュされる前に、コミットされていない変更があることを常に好むでしょう。
結果としてのブランチでのマージは、git pullほとんどの場合無意味です。マージが意味のあるものである場合、ブランチは異なる (および明示的にマージする) 必要があります。
http://stevenharman.net/git-pull-with-automatic-rebaseも参照してください。
他のリポジトリに存在し、それに基づいて別の作業を行う可能性のあるリビジョンは、決してリベースしないでください。その作業もリベースする必要があるからです。
ブランチをプッシュしてからリベースする場合は-f、次のプッシュにオプションを使用する必要があります。したがって、そのオプションを使用しない場合は、問題のある状況に陥ることはなく、自由にリベースできます。ただし、おそらく機能ブランチにプッシュする場合は-f、他の人がそのブランチでも作業している可能性があるときにリベースしたり、彼らとリベースを調整したりしないように注意してください。
そのため、独自の開発作業では、必ずリベースを行ってください (さらに、リベース -i および変更の結合と分割などを行って、より論理的なものにします)。しかし、複数の人が機能に取り組んでいる場合、リベースには調整が必要になり、もはや価値がなくなる可能性があり、公開された開発ブランチのリベースは基本的に立ち入り禁止です。