私が繰り返し「槌で打たれた」のを見たのは、それが適切な場合があることは確かですが、決してすべきではないということです。 git push --force
--forceはいつ使用される予定ですか？
私の現在の例：
push --forceはこれに対する適切な解決策ですか？
その場合、はい、強制プッシュを実行してその機能ブランチの履歴を書き直すときに、そのブランチで作業しているのはあなただけであるか、他の人がその意味を理解していると仮定します。
push -f誤ってプッシュした機密データをリポジトリから削除する必要がある場合は、本当に必要になります。その場合、 and を実行する必要がありgit filter-branchますgit push -f。この記事では、そのプロセスについて説明します。
push -fまた、ジュニア開発者がレポで何かばかげたことをしたときに、あなたがしなければならない例に出くわしました。とにかく、そもそも彼らに権利を与えたり、十分な訓練を与えたりするべきではありませんでした.
履歴の書き換えは、リポジトリをプルして、ブランチに基づいて独自の変更を加えた人にとって頭痛の種です。リモート履歴を書き換えて、下流の人々がそれを引っ張ると、彼らの変更はどこにもぶら下がってしまいます。(ドキュメントのアップストリーム リベースからの回復セクションを確認してください。)git rebase
そのため、他の人があなたのレポを使用している場合は、通常、元の変更をマージしてマージliveをプッシュする方がよいでしょう。リベースほどクリーンではありませんが、下流の誰もがあなたのリライトに追いつくためにファンキーなことをする必要はありません:
git checkout live
git merge --no-ff origin/whatever
git push origin live
live変更をメイン ブランチに戻す準備ができたら、いつでもリベースできます。
一方、リポジトリを使用しているのがあなただけである場合、または下流の人々がリモート履歴の書き換えを修正することに問題がない場合は、--force離れてください。
私は通常push -f、最初のプッシュの直後、まだ誰も私の変更をフェッチしていないことがわかっているとき、またはプロジェクトに取り組んでいるのが私だけのときです。
それ以外の場合は、履歴を書き換える限り、強制的なプッシュを回避する必要があります。