元に戻されたGitコミットを「元に戻す」方法を教えてください。

を使用してコミットされcommit、次にを使用して元に戻された変更がある場合、revertその元に戻すを元に戻す最善の方法は何ですか？

理想的には、履歴を書き直さないように、新しいコミットでこれを行う必要があります。

その変更をまだプッシュしていない場合は、 git reset --hard HEAD^

それ以外の場合は、復帰を完全に元に戻します。

もう1つの方法はgit checkout HEAD^^ -- .、それを行うことgit add -A && git commitです。

git cherry-pick <original commit sha>
元のコミットのコピーを作成し、基本的にコミットを再適用します

元に戻すと、同じことが行われますが、より厄介なコミットメッセージが表示されます。
git revert <commit sha of the revert>

これらのいずれの方法でもgit push、復帰後に新しいコミットが作成されるため、履歴を上書きせずに実行できます。
commit shaを入力するとき、通常必要なのは最初の5文字または6文字だけです。
git cherry-pick 6bfabc

コミットを元に戻すは、gitの他のコミットと同じです。つまり、次のようにして元に戻すことができます。

git revert 648d7d808bc1bca6dbf72d93bf3da7c65a9bd746

これは明らかに、変更がプッシュされて初めて意味があり、特に宛先ブランチにプッシュを強制できない場合（これはマスターブランチに適しています）です。変更がプッシュされていない場合は、他の投稿と同様に、チェリーピック、元に戻す、または単に元に戻すコミットを削除するだけです。

私たちのチームでは、主なブランチでコミットされたRevertコミットを元に戻すというルールを使用しています。これは主に履歴をクリーンに保つため、どのコミットが何を元に戻すかを確認できるようにするためです。

      7963f4b2a9d   Revert "Revert "OD-9033 parallel reporting configuration"
      "This reverts commit a0e5e86d3b66cf206ae98a9c989f649eeba7965f.
                    ...
     a0e5e86d3b6    Revert "OD-9055 paralel reporting configuration"
     This reverts commit 648d7d808bc1bca6dbf72d93bf3da7c65a9bd746.
                ...
     Merge pull request parallel_reporting_dbs to master* commit 
    '648d7d808bc1bca6dbf72d93bf3da7c65a9bd746'

このようにして、履歴を追跡し、全体のストーリーを把握できます。また、遺産の知識がない人でも自分で解決できます。一方、ものを選択したりリベースしたりすると、この貴重な情報は失われます（コメントに含めない限り）。

明らかに、コミットが元に戻されて複数回戻された場合、それはかなり厄介なものになります。

元に戻すことはトリックを行います

例えば、

もし abcdef、あなたがコミットされ、ghijklであるあなたがコミット戻ったときにあなたが持っているコミットしabcdef、その後、実行します。

git revert ghijkl

これは元に戻ります

私にはバカに見えます。しかし、私は同じ状況にあり、コミットを元に戻しました。私は番号を元に戻したので、「コミットを元に戻す」ごとに元に戻す必要がありました。

今私のコミット履歴は少し奇妙に見えます。

ペットプロジェクトなので大丈夫です。しかし、実際のプロジェクトでは、元に戻す前に最後のコミットに進み、すべての元に戻されたコードを1つのコミットとより合理的なコメントで復元します。

ここに私がそれをした方法があります：
ブランチmy_branchnameが元に戻されたマージに含まれていた場合。そして私は元に戻したいと思いましたmy_branchname：

最初にgit checkout -b my_new_branchnameからを行いmy_branchnameます。
それから私はないgit reset --soft $COMMIT_HASHところ$COMMIT_HASH、右のハッシュをコミットコミットされた前に、最初のコミットmy_branchname（参照git log）
その後、私は新しいコミット作るgit commit -m "Add back reverted changes"
それから私は新しい枝を押し上げるgit push origin new_branchname
その後、私は新しいブランチのプルリクエストを行いました。

それとも、可能性git checkout -b <new-branch>とgit cherry-pick <commit>の前とgit rebase降下にrevertコミット。以前と同様にプルリクエストを送信します。

「復帰を元に戻す」という考えが気に入らない場合（特に、多くのコミットの履歴情報が失われることを意味する場合）は、「障害のあるマージを元に戻す」に関するgitドキュメントをいつでも参照できます。

次の開始状況を考えると

 P---o---o---M---x---x---W---x
  \         /
   A---B---C----------------D---E   <-- fixed-up topic branch

（WはマージMの最初の復帰です; DとEは最初に壊れた機能ブランチ/コミットの修正です）

コミットAからEを単純に再生できるようになりました。これにより、元のマージに「所属」するものはなくなります。

$ git checkout E
$ git rebase --no-ff P

これで、ブランチの新しいコピーをmaster再びマージできます。

   A'---B'---C'------------D'---E'  <-- recreated topic branch
  /
 P---o---o---M---x---x---W---x
  \         /
   A---B---C----------------D---E

コミット後に元に戻されたステージングされていない変更とステージングされた変更を元に戻すには：

git reset HEAD@{1}

ステージングされていないすべての削除を復元するには：

git ls-files -d | xargs git checkout --