これまでのところ、「hg rebase」はあなたをどのように扱ってきましたか? バグや落とし穴を発見しましたか? どのような状況で mq を置き換えたり補完したりするのですか?
2272 次
3 に答える
7
リベースは、単純なケース (マージの競合がないかほとんどない) では非常に便利ですが、競合が多い場合は、通常のマージ + コミットと比較して、それだけの価値があるよりも問題になる可能性があります。
リベースはコミットを変更し、履歴を変更し、デフォルトで元のコミットを削除します。これは、悪い瞬間にあなたを襲った場合、非常に複雑な多くの意味を持ちます:
- 競合をどのように解決したかを確認する方法はありません。(つまり、元のコミットとリベースの差分。プッシュする前にそれらを保持して手動で削除することを選択しない限り)
- リベースされた各リビジョンが正常にマージされ、コミットする前に正常にコンパイルおよび実行されることをテストする方法はありません。リベースすると、コミットが変更されます。(上記と同じ例外)
- あなたが本当に分散したものを作っていて、多くのソースから共有/プルしているのであれば、リベースしようとしているコミットを共有しないように細心の注意を払う必要があります。
- さらに、上記のシナリオで、誤ってリベースしてから、これらのリベース前のコミットを誰かから引き出した場合、コミットのセットが 2 つになり、そのうちの 1 つのセットを 'hg strip' する必要があります。(ここでマージしようとはしていません。)
問題は、編集履歴をリベースすることです。これは、「更新」時にSVNが行うことです。したがって、間違いなく使用できるものですが、未解決のコミットが多数あり、多くの競合が予想される場合は、代わりにマージをお勧めします。
于 2009-03-01T00:10:18.023 に答える
3
MQ (Mercurial Queues) に対する最大の利点は、キューに入れられたパッチを変更されたベースレイヤーにプッシュすると、最終的に .rej ファイルが作成され、パッチを手動で修正する必要があることです。リベースを使用すると、代わりにマージが行われ、標準のマージ解決ツールが起動されます。
于 2009-02-23T04:08:33.507 に答える
0
リベースされたブランチを指すタグに問題があります。
.hgtags@XXXXXXXXXXXX、2 行目: タグ 'XXX' は不明なノードを参照しています
タグが正しく変換されていないようです。
于 2009-11-25T14:06:14.147 に答える