使った
git リセット --hard dc082bc...いくつかの悪いコミットのために、ブランチを必要な前の状態に戻す。これにより、ローカルブランチがうまく巻き戻されました。ただし、もう一度開始できるように、「origin」のブランチを同じコミットに巻き戻したいと考えています。元のブランチ (マスターではない) をこのコミットに戻す方法を誰か教えてもらえますか?
git push origin master を試しましたが、次のエラーが発生します
! [拒否] 分岐 -> 分岐 (非早送り) エラー: いくつかの参照を 'git@github.com:xxx/xxx.git' にプッシュできませんでした 履歴が失われないように、早送り以外の更新は拒否されました 再度プッシュする前に、リモートの変更をマージしてください。「についての注意」を参照してください 詳細については、「git push --help」の「早送り」セクションを参照してください。
私の以前の回答に追加し、強制が他の貢献者のローカルリポジトリを本当に台無しにする可能性があるという事実に対処するためにgit push、git 1.8.5 (2013 年第 4 四半期) には新しいオプションが表示されます。
git push --force-with-lease
このスレッドでそのオプションの起源を参照してください。
origin' ' で、検査のためにフェッチした後に強制または削除しようとしているブランチに何かが発生した場合、他の人の作業が失われる可能性があります。ブランチを巻き戻して再構築するという決定に気付いていない誰かが、ブランチをリベースするためにフェッチしてから、リベースの結果に置き換えるためにプッシュするまでの間に、ブランチにプッシュしようとする可能性があります。
make these pushes safer必要に応じて、ユーザーが次のことを "git push"伝えられるようにすることができます。「ブランチ」の値がまだこのオブジェクトにあるという仮定に基づいて、強制/削除しています。
その前提が成り立たなくなった場合、つまり、このプッシュの準備を開始してからブランチに何かが起こった場合は、先に進まず、このプッシュを失敗させてください。
コミット 28f5d17--force-with-leaseで完全なドキュメントを見ることができます
--force-with-lease特に指定がない限り、現在の値が合理的なデフォルトと同じであることを要求することにより、更新されるすべてのリモート参照を保護します。今のところ、「何らかの妥当なデフォルト」は暫定的に「更新されるリモートの参照用に持っているリモート トラッキング ブランチの値」として定義されており、そのようなリモート トラッキング ブランチがない場合はエラーになります。
それはそのオプションの「リース」部分を説明しています：
"
force-with-lease": リベースされた履歴がどうあるべきかを決定するためにフェッチしたときに参照のリースを取得したと想定し、リースが壊れていない場合にのみプッシュバックできます。
これはすでにテストされており、「git.git での調理について (2013 年 8 月 7 日; 水 28 日)」で言及されています。
ちなみに、通常の「must fast-forward」をオーバーライドするプッシュは、次のように でクックされている「
force-with-lease」オプションを使用して行われましnextた。
$ git fetch ko next
$ anchor=$(git rev-parse --verify FETCH_HEAD)
$ for remote in ko repo gph github2
do
git push --force-with-lease=refs/heads/next:$anchor $remote next
done
注: " git push --force-with-lease" は、プッシュを強制 (または早送り) する必要があるかどうかを報告するように教えられています。
したがって、このコマンドは git 2.8 (2016 年 3 月) での出力でより詳細になります。
push: の ref ステータス レポートを修正しました
--force-with-leaseプッシュ オプションでは、
--force--with-leaseより詳細なステータス情報が得られません--force。
特に、出力は、参照が強制的に更新された場合でも、参照が早送りされたことを示しています。
Git 2.13 (Q2 2017) で説明されているように、そのオプションが無視/バイパスされることに注意してください。
git push --force強制的に押してみることができます。
--force
通常、コマンドは、上書きに使用されたローカル ref の先祖ではないリモート ref の更新を拒否します。このフラグはチェックを無効にします。
これにより、リモート リポジトリがコミットを失う可能性があります。注意して使用してください。
そのため、多くの人がすでに同じブランチをオリジンからプルしている場合、彼らの側でリベースの問題が発生する可能性があります。
その操作は、ebneterが (コメントで) 指摘しているように、サーバー側でブロックできます。
ただし、リモートの構成方法によっては、これが機能しない場合があり
ます。私の中央リポジトリはすべて と で構成receive.denyNonFastForwards = trueさreceive.denyDeletes = trueれています。その場合、そのような操作はリモートサーバーで行う必要があります。
ただし、GitHub の場合、GitHub リポジトリを管理しているユーザーがそのような設定をすぐに利用できるわけではありません。
したがって、git push --force間違ってしまった場合は、GitHub サポートにケースを開いて、ローカル (つまり「GitHub」) の reflog をチェックし、古いコミットを復元できるかどうかを確認するだけです。(私が最近思い出したように
、reflog はローカルであるため、 GitHubサーバー側で ' ' または ' ' がまだ行われていない場合にのみ、新しいコミットに置き換えられたコミットが表示されます)push --forcegit gcgit prune
したがって、マルコ・セッピは（コメントで）次のように主張しています。
これは、プッシュを強制すると、他の貢献者のローカルリポジトリを本当に台無しにする可能性があります-ただし、それが必要悪である場合もあります(Gitを使用している私の生涯でこれを2回行う必要があったかもしれません)
git reset&&git push強制上書き# master commit uid
$ git reset --hard b9e3f7f2f66674901b467183dd81d493e50677f5
# git push branch_name --force
# local master
$ git push origin master --force
# remote master
$ git push origin/master -f