web-dev-qa-db-ja.com

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

ここで少し問題に遭遇しました。Gitに問題固有のブランチ28sがあり、それを一般的なdevelopブランチにマージしました。速すぎたことがわかったので、git-revertを使用してマージを取り消しました。しかし、今では28sをdevelopにマージするときが来ましたが、git-mergeコマンドは元のマージを確認し、すべてが正常でブランチがすでにマージされていることを喜んで発表します。私は今何をしますか？ 'Revert "Revert" 28s-> development ""'コミットを作成しますか？それを行うのに良い方法ではないようですが、現時点では他に想像することはできません。

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

Git log output

gitgit-mergegit-revert
199
Toms Mikoss

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

---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はそれについても考えずにそれを行います。

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

可能な限り、たとえば、メインツリーにマージされた問題を見つけた場合、マージを元に戻すのではなく、 really hardを試してください。 to：

  • マージしたブランチに問題を二分し、修正するだけです。
  • または、それを引き起こした個々のコミットを元に戻そうとします。

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

149
J-16 SDiZ

あなたはそのような歴史があると仮定しましょう

---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が元に戻され、いくつかの新しいコミットが追加されることが明確に示されます。

47
Maksim Kotlyar

ワークフローを台無しにせずに元に戻すには：

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

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

7
Sam Dufel

GITで元に戻すには：

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

git-revertを使用する代わりに、このコマンドをdevelブランチで使用して、（単に元に戻すのではなく）間違ったマージコミットをthrow away（元に戻す）にすることもできます。

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の履歴から消去されます）。

3
knweiss

同じ問題に直面したときにこの投稿を見つけました。ハードウェイのリセットなどを行うために上記のwayyyが怖いのを見つけました。

代わりに、ブランチに戻りたいコミットをチェックアウトしましたgit checkout 123466t7632723。その後、ブランチgit checkout my-new-branchに変換されます。その後、不要になったブランチを削除しました。もちろん、これはあなたが台無しにしたブランチを捨てることができる場合にのみ機能します。

1
Claire

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

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

1
Misha Mostov