git pull --rebaseを使用すると、git が履歴を書き換え、プルしたばかりのブランチ内のすべてのコミットの後にローカル コミットが発生するように移動する ことを理解しています。
私が理解できないのは、これがいかに悪いことになるかということです。git pull --rebase人々は、他の人が引っ張ることができないブランチで終わる可能性がある場所でトラブルに巻き込まれることについて話します。しかし、あなたがしているのは、プルしたブランチの上でまだ公開されていないローカルのコミットを再生しているだけなので、それがどのように可能かわかりません。それで、何が問題なのですか？
コミットの一部のみを公開 (プッシュ) した場合にのみ問題になります。これらのコミットが既にある他のリポジトリにマージするのが難しくなるためです。SHA1 が変更されたため、Git はそれらのリポジトリでそれらを再度再生しようとします。
(これらのコミットを再度プッシュしていない) 場合、リベースは安全なはずです。
したがって、ここでの問題は次のとおりです。リベースしているすべてのローカルコミットがまだ実際にまだローカルであると確信していますか? ' ' の後の ' '
は確かですか?git pull --rebasegit pull --rebase
「プライベート ブランチ」(プッシュしたことはなく、プッシュするパブリック ブランチでのみマージまたはリベースしたブランチ) で作業している場合は、いつでもプライベート ブランチをリベースしても安全です。
結局、それはすべて、確立するために選択したマージのワークフローに依存します。
ブランチにコミットします。押す。別のブランチにマージします (パッチ ブランチと新しい開発ブランチの 2 つのベースラインを維持しているとします)。あなたが追跡しているサーバーブランチに他のコミットがプッシュされたことを認識してください。--rebase をプルします。突然、新しいハッシュに対して各コミットを再作成し、マージ コミットを破棄しました。
誰もあなたからプルしておらず、コミットを (リベース前に) 他の場所にプッシュしていなければ、理論的には問題ありません。ただし、Git はマージを適切に処理するように設計されており、プルしてリベースする代わりにプルしてマージすると、全体的な作業が少なくなることがあります。
Git は分散ソース管理システムであることを思い出してください。プッシュ先の中央リポジトリからプルする必要はありません。特定のワークフローでは、変更を直接プルできます。そのような場合、履歴を書き換えると、あなたが話している問題が確実に発生する可能性があります