多くの人がそれについて話し、git rebaseそれが何をするかを見てきました。たとえば、Hg: git のリベースのようなリベースを行う方法と、それが何を達成するか (線形の履歴を与える) について話している人がいます。しかし、なぜあなたがこれをやりたいのか理解できません。
戻ってコミット履歴を修正するのは、大きな出費のように思えます (これには、多方向の競合を伴ういくつかの醜いマージが含まれているに違いありません)。そして、それが非常に誤解を招く可能性のあるケースを想像することができました (たとえば、2 人が同じ問題を異なる方法で解決したが、歴史は彼らの仕事が並行して行われたことを示していない場合。それは簡単に批判や恨みにもつながる可能性があるようです)。一部の高圧コーディング環境では）。
得られるのは、理解しやすいが正しくない履歴グラフです。それが努力に値する理由は何ですか？
前もって感謝します。
Rebase は、単一のコミットまたは短い時間枠 (数時間または数分) で開発された少数のコミットをプッシュする場合に最も役立ちます。
共有サーバーにプッシュする前に、オリジンの HEAD に対して作成されたコミットをプルする必要があります。そうしないと、非早送りプッシュが作成されます。その際、マージ ( git pull) またはリベース ( git pull --rebase) 操作のいずれかを選択できます。マージ オプションは、技術的にはより魅力的ですが、追加のマージ コミットを作成します。小さなコミットの場合、変更ごとに 2 つのコミットが発生すると、実際には履歴が読みにくくなります。これは、マージ操作がコミットのメッセージから注意をそらすためです。
典型的な共有開発ツリーでは、すべての開発者が何らかのバリエーションを実行して共有ブランチにプッシュすることになりgit pull; <resolve conflicts>; git pushます。git pullなしで使用している場合、実際には並行開発が行われていないにもかかわらず、--rebaseほぼすべてのコミットがマージ コミットを伴うことになります。これにより、実際には直線的な一連のコミットから、絡み合った履歴が作成されます。このため、git pull --rebase短期間の開発に起因する小さな変更には が適していますが、マージは存続期間の長い機能ブランチの統合のために予約されています。
これはすべて、ローカルコミットのリベース、または密接につながっている同僚 (同じ部屋に座っている) によって共有されている短期間の機能ブランチのリベースに適用されます。コミットが定期的にブランチにプッシュされ、続いて他のブランチにプッシュされると、決してリベースしないでください。