以前git filter-branchは、自分のリポジトリの 1 つで多数のコミットを更新していました (作成者とコミッターの電子メールが間違っていたのを修正しました)。私が使用したコマンドは次のとおりです。
git filter-branch -f --env-filter "GIT_AUTHOR_EMAIL='mike.r.anderson.13@gmail.com'; GIT_COMMITTER_EMAIL='mike.r.anderson.13@gmail.com';"
続いて git pull を実行してリモート リポジトリと同期します
これはうまくいきましたが、GitHub の履歴を見ると、変更前と変更後の 2 つの完全な履歴が表示されます。最終的に一点で合流します。
これは問題ですか？または、両方の履歴を安全に残すことができますか?
まず、git filter-branch歴史を書き直すことを意図しており、別の歴史と並行して歴史を作成することはありません。filter-branchマージして操作を終了した場合は、それを正しく使用していません。
これは確かに混乱を招く可能性があります。歴史の 1 つの線が表示されることもあれば、別の線が表示されることもあります。同じ変更を行う履歴の行が複数ある場合はいつでも、それは悪いことです。特定の変更を導入したコミットを見つけようとしているbisectやなどの操作を想像してみてください。blame現在、実際には同じことを行う 2 つの歴史的なコミットがよくあります。どちらが必要ですか?
のような基本的な操作でさえgit log、日付順の場合、「重複した」コミットが長時間実行されることがあります。明らかに望ましくない動作です。
より理想的な注意点として、このような小さな問題を修正するために履歴を書き直す必要があるでしょうか? git にはまさにこの状況のための機能があります: " mailmap ".
一般に、セキュリティ上の懸念がない限り、公開された履歴を書き換えることは避けるべきです (つまり、開示の問題...そして、一度秘密が公開されたら、可能であれば、単にその公開を制限するのではなく、秘密を無効にすることが最善です)。 、またはこのような状況で、悪い履歴が公開され、リポジトリが使いにくくなっています。
filter-branchまたはなどの履歴書き換えコマンドrebaseを公開された履歴に対して実行すると、git がローカル コミットを既存のアップストリーム コミットに「基づいている」と見なさなくなることに注意してください。このため、通常どおりにプッシュすると、次のようなエラーが発生します。
! [rejected] master -> master (non-fast forward)
したがって、プッシュを「強制」する必要がありますgit push -f。applyに関する標準的な警告-f(他の人のコミットを壊さないように注意してください) と、もちろん公開履歴の書き換えに関する警告です。
公開履歴の書き換えに関する警告は別として、並列履歴を作成せずに実際に書き換える限り、心配する必要はありません。完全を期すために、主な潜在的な問題の概要を見てみましょう。
3 番目の点により、「古い」履歴のタグを有効にしておくことをお勧めします。これにより、commit-id に言及する歴史的な議論が引き続き有効な場所を指すようになります。ただし、そのタグが新しい開発に使用されないことが明確になるように、タグに名前を付けてください。
まず第一に、間違ったコミット済みの電子メールを含むコミットがまだ履歴に残っているので、本当に何かを得たのでしょうか? :-)
それ以外は、ツールよりも主にユーザーを混乱させると思います。これはさらに悪い状況になる可能性があります。たとえば、どちらのコミットが選択されても、マージコミットの最初の親に依存する可能性が最も高く、かなりランダムになります...git blame
一般に、どのような種類の履歴をブラウジングするのも、ツールにとってではなく、ユーザーにとって苦痛になります。時間の経過とともに修復が難しくなるため、何らかの方法で今すぐ修復することをお勧めします。