6

それで、昨日、アップストリーム ブランチをローカル トピック ブランチにリベースしようとしたときの奇妙な競合に関する質問を投稿しました。

最後にgit rebase --merge upstream、以前のリベース以降に触れていないファイル内の多くの競合を使用して解決しました。

このような場合のリベースについての私の理解では、コミットをそのトピック ブランチから切り離し、上流のブランチからコミットを適用してから、それらの上にコミットを (パッチとして) 適用します。そのため、早送り操作になってしまいます。私が理解していないのは...上流からのコミットとマージの競合が発生するのはなぜですか。それらもパッチとして適用されますか? 私はただ...同じブランチから来た前のコミットの上にいくつかのコミットを「溶接」する行為だと思いましたか？

触れていないファイルに多くの競合があったため、これを求めています。ああ、私はこのアップストリーム ブランチで毎日リベースを行っています。

アップデート

アップストリームからトピック ブランチに持ち込まれたコミットの一部で、SHA-1 ID が変更されていることに気付きました。Gitがこれを行う原因を知っている人はいますか? それは--mergeスイッチでしょうか？

私のgitバージョンは1.5.6.5です

4

1 に答える 1

3

リベースは履歴を書き換えます。すでにリモートにプッシュされているコミットをリベースすると、苦痛の世界に突入します。このようにリベースを続けると、さらに悪化します。Rebase には利点がある場合もありますが、マージのようなカジュアルなツールではなく、IMOの特殊なツールです。

そして、それらの上に私のコミットを（パッチとして）適用します。

はい、新しいコミットとして

ですので、早送り操作になってしまいます

いいえ。早送りはHEAD、そのブランチのポインタを移動するだけです。リモートから新しいオブジェクトを導入し、その上にパッチを適用しています。

ローカルとリモートが で最後に同期していてA1、(ローカルで) を追加したA2とA3コミットし、リモートが and を追加したことを発見したB1とB2します。子孫) にパッチを適用し、新しいコミットとしておよびにパッチを適用します(したがって、新しい SHA-1)および. A2A3B1B2A1A2A3 A2'A3'

したがって、ローカル履歴は次のよう になります。A1 - B1 - B2 - A2' - A3' これは早送りではありません。

于 2011-01-07T19:21:53.147 に答える