私が言ったことはあまり明確ではないかもしれませんが、コードを書いているときに、もうやりたくないことがわかったので、git replace --hard <versionnumber>
を使用しました。前のバージョンに戻るには、バージョンを書き直して、書き終えてリモート ウェアハウスに送信したいときにエラーが報告されるようにします。
リーリー
黄舟2017-06-16 09:21:00
まず第一に、あなたの説明によると、あなたはgit reset --hard
,那就可以推断出你已经 add
和 commit
过了。
其次,根据报错,可以推断出你已经 push
を使用しているため(この推論は、あなただけがマスターブランチの変更権限を持っているという事実に基づいています。
その後、git reset --hard
を実行すると、履歴レコードをリモート レコードと直接マージすることはできません。それがこのエラーが発生する理由です。
たとえば、リモートは A -> B -> C -> D
,你 git reset --hard
之后是 A -> B
。这时候除非远程那边抹掉 C
和 D
で、
A -> B
が続きます。このときリモート側でC
とD
を消去しないとマージできません。
git push origin master --force
そのため、現時点ではを使用してリモートレコードを強制的に上書きする必要があります。
git pull
。否则,你的本地又会变成 A -> B -> C -> D
。因为 git pull
相当于 git fetch
+ git merge
指示に従って使用しないでください
A -> B -> C -> D
(以下の内容は上記の例に基づいており、リモートは
git revert
。其实,git reset --hard
和 git revert
git revert
については上の階で説明しました。実際、
git revert
の両方で「コードのロールバック」を実現できます。しかし、違いは次のとおりです:
git revert
会把你的本地变成 A -> B -> C -> D -> E
。其中,E
干的事儿是删除 C
和 D
。这样做的好处在于,你 git push origin master
就不会有上面的报错了。但,历史线上还是会保留 C
和 D
这两个 commit。如果使用这个命令,记得要 add
然后 commit
git reset --hard
会直接删掉 C
和 D
,形成 A -> B
这样的结果。好处在于更直接更彻底。缺点在于,首先要通过 git push origin master --force
去强行更改。其次,一旦你后悔了,除非根据本地的 reflog
C
と D
を直接削除し、A -> B
のような結果を形成します。利点は、より直接的かつ徹底的であることです。欠点は、最初に を通じて変更を強制する必要があることです。第 2 に、一度後悔したら、ローカルの reflog
に基づいて HEAD ポインタを直接復元する以外に方法はありません。
漂亮男人2017-06-16 09:21:00
一般的に、この状況は避けるようにしてください。
リモートマスターへの許可がある場合は、次のことができます:
リーリーより合理的なアプローチは git revert を使用することです
分割線を編集する
別の学生 @S1ngS1ng はより詳細な回答をしましたが、どれも使用できるという点を指摘しましたが、それでも git revert の方がより適切なアプローチであると強調しました。
複数人による開発シナリオの場合、最新のコードがリモート マスター上で他の人によってプルされているか、他のブランチにマージされている可能性が非常に高くなります。この場合、相手がまだプッシュしている可能性があるため、リセットは無効になります。コミットを削除したいと思います。
つまり、どれでも使えるというこの考えには実際には限界があります