git - マージする代わりにトピックブランチをリベースすることの欠点は何ですか？

Question

私の現在のパターンは、mergeブランチが終了したら、メインの開発ブランチにブランチをトピックすることです。最近、ログを見るのがちょっとおかしくなってきたので、rebase代わりに使用するように切り替えることを検討していました。

トピック/機能ブランチrebaseの代わりに使用することの考えられる欠点は何ですか？merge

Answer 1

rebase を使用する際の主な欠点は、rebase をローカルでのみ使用する必要がある (読み取りが必要) ことです。つまり、何かがプッシュされたら、その後はリベースしないでください。履歴の書き換えは問題ありませんが、リモートで履歴をいじり始めるとすぐに、事態は非常に厄介になります。

編集

もう 1 つの欠点は、真の履歴が実際に失われているという事実です。これは、とりわけ、メイン ブランチの一部のように見えるため、トピック ブランチに (簡単に) 戻ることができないことを意味します。また、元のトピック ブランチからのものを思い出すために最善を尽くして、一度に 1 つのコミットを選択する必要があるため、変更を元に戻すことははるかに苦痛になります。インタラクティブなリベースを使用している場合、またはさらに悪いことに、コミットを押しつぶした場合、これは大きな頭痛の種になる可能性があります。

Answer 2

欠点には、開発中にリビジョンが実際の状態と一致しない、 のようなフラグを使用してマージ間のコミットを非表示にする機能が失わ--first-parentれる、後でリベースする予定がある場合にブランチを共有するのが難しいなどがあります。git help logログがおかしくなったら、もう一度見てください。必要に応じて柔軟性を犠牲にすることなく、希望どおりに見えるようにするフラグの組み合わせが存在する可能性があります。