Git で元に戻されたマージを再実行する

StackOverflow https://stackoverflow.com/questions/1078146

  •  21-08-2019
  •  | 
  •  

質問

ここで少し問題が発生しました。問題固有のブランチがありました 28s Git で、一般的にマージしたもの develop 支店。実行が速すぎたことが判明したので、git-revert を使用してマージを元に戻しました。しかし今、融合の時が来た 28s の中へ develop, しかし、git-merge コマンドは元のマージを確認し、すべてが順調でブランチがすでにマージされていることを喜んで通知します。今何をすればいいでしょうか？'Revert "Revert "28s ->development"" ' コミットを作成しますか?良い方法とは思えませんが、現時点では他に考えられません。

ツリー構造は次のようになります。

Git log output

役に立ちましたか？

解決

「元に戻す」必要があります。それをどのように元に戻したかによっては、思ったほど簡単ではないかもしれません。見てください このトピックに関する公式文書.

---o---o---o---M---x---x---W---x---Y
              /
      ---A---B-------------------C---D

許可するには:

---o---o---o---M---x---x-------x-------*
              /                       /
      ---A---B-------------------C---D

しかし、それはすべてうまくいくのでしょうか？確かにそうです。マージを元に戻すことができ、純粋に技術的な角度から、Gitは非常に自然にそれを行い、本当の問題はありませんでした。
それは、「マージの前の状態」から「マージ後の状態」への変更と考えていました。
複雑なものも、奇妙なことも、本当に危険なことはありません。Git は何も考えずにそれを実行します。

したがって、技術的な角度から、マージを戻すことに何の問題もありませんが ワークフローの角度から、それはあなたが一般的に避けようとするべきものです.

たとえば、可能な場合は、メインツリーに統合された問題が見つかった場合、 マージを元に戻すのではなく、試してみてください 本当に 難しい:

  • 問題をマージしたブランチに分割し、それを修正するだけです。
  • または、原因となった個々のコミットを元に戻してみてください。

はい、それはより複雑であり、いいえ、それは常に機能するとは限りません（時には答えは次のとおりです。「おっと、まだ準備ができていなかったので、本当にマージしてはいけません。本当に元に戻す必要があります 全て マージの」）。したがって、マージを元に戻す必要がありますが、マージをやり直したい場合は、戻ることでそれを行う必要があります。

他のヒント

あなたは、このような歴史を持っていると仮定しましょう。

---o---o---o---M---W---x-------x-------*
              /                      
      ---A---B

A、BがコミットおよびWを失敗場合は、 -

Mの復帰されます

私が見つけた問題を修正開始する前に、私はチェリーピックWのが私の枝にコミットんので、

git cherry-pick -x W

それから私は、Wが私のブランチにコミット元に戻す

git revert W

私は固定を続けることができた後。

最後の歴史は次のようになります：

---o---o---o---M---W---x-------x-------*
              /                       /     
      ---A---B---W---W`----------C---D
私はPRを送信すると、

それは明らかPRが復帰を元に戻すされ、いくつかの新しいコミットを追加することを示しています。

ワークフローをあまり混乱させずに、取り消しを元に戻すには、次のようにします。

  • ローカルにdevelopのゴミ箱コピーを作成する
  • 開発のローカルコピーのコミットを元に戻します。
  • そのコピーを機能ブランチにマージし、機能ブランチを Git サーバーにプッシュします。

準備ができたら、機能ブランチを通常どおりマージできるようになります。ここでの唯一の欠点は、履歴に余分なマージ/元に戻すコミットがいくつか残ることです。

GITに復帰を元に戻すには：

git revert <commit-hash-of-previous-revert>

使用する代わりに git-revert このコマンドを devel に分岐する 捨てる 間違ったマージコミットを（単に元に戻すのではなく）（元に戻します）。

git checkout devel
git reset --hard COMMIT_BEFORE_WRONG_MERGE

これにより、作業ディレクトリの内容もそれに応じて調整されます。 気をつけて:

  • 変更を保存します 開発ブランチでは（間違ったマージであるため）、それらもによって消去されるため git-reset. 。あなたが指定したものの後にすべてをコミットします git reset 議論はなくなります！
  • また、リセットが履歴を書き換えるため、変更が他のリポジトリからすでに引き出されている場合は、これを行わないでください。

を勉強することをお勧めします git-reset これを試す前にマニュアルページを注意深く確認してください。

リセット後、変更を再度適用できます。 devel そしてそうします 

git checkout devel
git merge 28s

これは実際のマージになります 28s の中へ devel 最初のもののように（現在はGitの歴史から消去されています）。

同じ問題に直面したときに

私はこの記事を見つけました。私は、私はしたくない、私は何かを削除する羽目になるなどをリセットhardsを行うには怖いとwayyy上で見つけ、それを取り戻すことはできません。

その代わり、私は枝が戻っ例えばに行きたかったコミットチェックアウトgit checkout 123466t7632723。そして、分岐git checkout my-new-branchに変換します。私はその後、私はこれ以上を望んでいなかったブランチを削除しました。あなたがめちゃめちゃに枝を捨てることができます場合はもちろん、これはのみ動作します。

私はあなたが復帰を元に戻すための手順の下に従うことをお勧めします、SHA1を言います。 

git checkout develop #go to develop branch
git pull             #get the latest from remote/develop branch
git branch users/yourname/revertOfSHA1 #having HEAD referring to develop
git checkout users/yourname/revertOfSHA1 #checkout the newly created branch
git log --oneline --graph --decorate #find the SHA of the revert in the history, say SHA1
git revert SHA1
git push --set-upstream origin users/yourname/revertOfSHA1 #push the changes to remote

これで分岐users/yourname/revertOfSHA1のためのPRを作成します。

  1. 元のマージの前のコミット時に新しいブランチを作成します - それを「develop-base」と呼びます
  2. 「develop-base」の上で「develop」の対話型リベースを実行します（すでに最上位にある場合でも）。インタラクティブなリベース中に、マージ コミットとマージを元に戻したコミットの両方を削除する機会があります。git 履歴から両方のイベントを削除します

この時点で、通常のように機能ブランチをマージできるクリーンな「開発」ブランチが作成されます。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top