私は Git でのリベースの意味を理解しようとしていますが、このシナリオでリベースを使用することをお勧めするかどうかについて質問があります。
「develop」という別のブランチから分岐した「feature」というブランチがあります。「機能」でいくつかのコミットを行いましたが、機能がまだ開発中であり、「機能」のコミットがリモート リポジトリにプッシュされていないため、まだ「開発」とマージしていません。
「開発」をチェックアウトしていくつかの修正を行う場合、「開発」が「機能」と同期するように「機能」ブランチにリベースするのが賢明ですか?
「開発」で「機能」をリベースします（もちろん、「機能」がローカルブランチであると仮定します）
「develop」を「feature」にマージすると、冗長なマージ コミットが作成されます。ただし、リベースを実行すると、マスターからのすべての変更が統合され、余分なコミットを作成することなく、「機能」を「開発」とマージする準備が整う前にすべての競合を解決できます。
反対する人も確かにいます。しかし、私はクリーンで読みやすい歴史が好きです。私がよくすることは、その機能を使い終わったら、 I rebase、次に I ということmerge --no-ffです。そうすれば、履歴は機能ブランチがあったことを明確に示しています。
- * - * - - - - - - - * - * -
\ /
* - * - * - *
問題は、私が「継続的に」競合を解決するのが好きだということです。競合が発生するたびに、面倒になる前に解決できるように、早い段階でそれを知りたいと考えています (継続的インテグレーションの理由と同様です)。頻繁にマージするという戦略に従うと、多くのマージ コミットが発生します。頻繁にリベースすることで、それらを回避できます。
マージを使用できるが、マージコミットを使用しない別の戦略があります - git rerere を有効にすることができます:
git config --global rerere.enabled true
この記事で説明されているように、中間マージを実行し、競合を解決してから、マージ コミットをリセットできます。rerere 機能は、「機能」ブランチの最終的なマージを行うときに、Git に競合の解決を記憶させます。