私は git が初めてで、git rebase を使用する「正しい」方法について少し混乱しています。
リベースと競合解決のプロセスが完了すると、途中で気が変わっていないかのように履歴が表示されるという考えですか?
たとえば、コミット A とコミット B があるとします。コミット A はいくつかの重要な変更を行いますが、後でコミット B で削除する関数も導入します。リベースすると、コミット A で導入された関数から競合が発生します。
ここで応答する「正しい」方法は何ですか? 関数を完全に導入しないようにコミット A を編集してから、コミット B を完全にスキップする必要がありますか? もしそうなら、コードの進化に関する重要なコンテキストを見逃していませんか?
コミット B をコミット A にリベースすると仮定しています。
競合がある場合は、コミット A を変更しないでください。これは、コミット B の前にコードが変更されたことを表すためです。代わりに、コミット B (履歴の後半の編集) を変更して、競合を解消し、バグを修正します。
通常、マージまたはリベースを自由に使用できます。あなたの git プロジェクトにあなたが 1 人しかいない場合でも、それは問題ではありません。大規模なグループが優先される場合があります。おそらくリベースが好きな人もいるので、すべてが線形であるように見えます。他の人は、実際に起こったことと一致するため、マージを好みます。
大規模なプロジェクトでは、(おそらく履歴を単純化するために) マスター ブランチにマージして戻す前に、ブランチを 1 つのコミット (インタラクティブなリベースを使用) に絞り込むこともできます。
私の意見では、それは問題ではありません。コミットをリベースするのは、通常、一部の機能を完了したか、何らかのマイルストーンに到達し、履歴を「書き換え」たいためです。本質的に、詳細に入るよりも、自分が行ったことの高レベルの概要に関心があります。
リベースの一部として特定のコード変更を強調したい場合は、それらをコミットメッセージに入れます。
「そうなら、コードの進化に関する重要な文脈を見逃していませんか」
そうです、しかしそれがリベースのポイントです。リベースは、履歴を希望どおりに書き換えます:-)
インタラクティブなリベースでリベースされている同じブランチ、または別のブランチで、コミットがどこにあるかについては言及していません。
別のブランチを仮定します。リベースを行うポイントは、一方のブランチのコミットを並べ替えて、もう一方のブランチの最後に追加することです。競合が発生した場合は、コミットを修正する必要があります。他のコミットの後にコード化された場合、それが機能が日の目を見ないことを意味する場合は、そうです。
コミットの時間的な順序がコンテキストにとって重要な場合は、代わりにマージしてください。