リベースの安全性に関する git の質問はたくさんありますが、公開履歴を書き換えるのは無礼であることを覚えている限り、安全であるべきだというコンセンサスがあるようです。あなたが引いているもの、あなたは安全です。
ただし、私に一時停止を与えるこの1つの答えがあります：
https://stackoverflow.com/a/2597107/1339987
ブランチにコミットします。押す。別のブランチにマージします (パッチ ブランチと新しい開発ブランチの 2 つのベースラインを維持しているとします)。あなたが追跡しているサーバーブランチに他のコミットがプッシュされたことを認識してください。--rebase をプルします。突然、新しいハッシュに対して各コミットを再作成し、マージ コミットを破棄しました。
これで遊んでみましたが、問題のシナリオを再現できませんでした (より複雑なマージを作成する必要があるかもしれませんが、これまでのところ失敗しています)。そこで、このシナリオの説明と、理想的には、リベース プルに安全かつ比較的無頓着に頼ることができる一連の基準を求めています。
問題のシナリオは実際には可能ですが、その影響はあなたが信じさせられたほど深刻ではありません. git で何かがコミットされるとgit config gc.reflogexpireunreachable、少なくとも 30 日間はその作業を失うことはありません (デフォルトでは、によって構成可能)。
上記のシナリオが発生し、それを検出した場合は、リベースの前にそのブランチの前のヒントにいつでも戻ることができます。このヒントは、git reflog次のようにチェックアウトで時間を確認または指定することで見つけることができますgit checkout 'HEAD@{5 minutes ago}'。
何年にもわたって git を使用してきましgit pull --rebaseたが、pull コマンドは一般に、私が考えているよりも高いレベルで動作するため、使用したことはありません。私は同等のことを好む：
git fetch origin
git rebase -i origin/branch
明示的なブランチ名とインタラクティブなオプションがオンになってgit rebaseいるということは、何がリベースされているかを常に認識していることを意味します。ときどき、間違ったことをすると、驚いて、リベース エディターに巨大なコミットのリストが表示されることがあります。
また、短期またはおそらく中期の機能に取り組んでいるときは、ほとんどの場合、アップストリームの変更をマージするのではなく、ローカルでリベースします。これにより、変更がより明確になり、最終的に変更を中央リポジトリにプッシュするときに履歴が簡素化されます。
つまり、要約すると、コマンドは他の git コマンドと同じくらい安全ですが、予期しない状況に陥らないように、コマンドが何をどのように実行するかを理解する必要があります。
また、注意:git rebaseマージを保持しようとするオプションがあります。で指定する簡単な方法があるようには見えませんgit pull --rebase。
履歴がすでに公開されている場合、履歴の書き換えは失礼です。変更がローカルである場合、失礼な人はいません。
何かを変更し、git pull早送りだけではない場合は、マージが行われるため、履歴が多少乱雑になります。変更がまだ行われていない場合は、git pull --rebase履歴をきれいに保つために使用したいと思います (そして上流の変更を組み込みます)。
履歴を書き換えると、以前には存在しなかったコミットが作成され、読み取り/テストされていないことに注意してください。
これは基本的に、gerritがどのように機能するかです。許可されたユーザーのみが実際のリポジトリにプッシュします。ほとんどの場合、gerrit レビュー サーバーにプッシュし、gerrit にマージを任せます。最終的にプルすると、リポジトリの「集中型」バージョンが得られ、関連するrepoツールがブランチをマージする代わりに常にリベースします。
このモデルでは、ユーザーは常に rebase でプルします。これまでのところ、Androidでうまく機能しています。