11

私は数週間前にマージが実行されたリポジトリで作業していますが、フラグを使用していることを発見したばかりで--strategy=ours( --strategy-option=ours フラグを使用することになっていました)、HEAD に変更を適用していません。ただし、変更を適用する必要があります。Git はすでにブランチがマージされていることを認識しており、ブランチの履歴にコミットされています。

この種のマージは、次を使用して元に戻すことはできませんgit revert -m ...

ファイルを変更するためにマージを元に戻したり再適用したりする適切な方法は何ですか?

master  A - B - E - F - G ---> L - M - N
             \     /
topic         C - D

(F)このシナリオでは、マージ コミットが原因です。

4

3 に答える 3

9

この問題の解決策を発見しました。不完全なマージを元に戻す方法については、Linus が書いた手紙にすべて記載されていました。私たちのgit merge --strategy=ours topic場合は意図したものではありませんでした。不完全なマージであっても元に戻すことはできず、長い間プッシュされているため、元に戻すコミットを元に戻すことができずに元に戻すマージ コミットを行うのと同じ効果があります。

解決策は、トピック ブランチをチェックアウトrebase --no-ffし、最初のコミットから実行してから、そのブランチをマスターにマージすることでした。

git checkout topic
git rebase -i --no-ff <C>
git checkout master
git merge topic

これにより、次の結果が得られました。

fixed–topic   C'–––D'––––––––––––––––––––-
             /                            \
master  A–––B–––E–––F–––G –––&gt; L–––M–––N–––F2
             \     /
topic         C–––D

この詳細を本当に理解するには、リベース オプションを使用して障害のあるマージを元に戻す方法--no-ffのレターの最後の部分を読んで、ブランチを再作成してください。

于 2013-01-09T06:10:41.890 に答える
4

@Highway of Life には素晴らしい答えがあります。1 つのことは、リベースされたコミットが新しい別のコミットのように見えることです。これは、多くの場合、望ましくない可能性があります。同じコミットをもう一度マージしたかったのですが、これgit-mergeを妨げています。しかし、git でやりたいことを実行することはいつでも可能であると、私は何度も思います。

  1. Highway of Life の指示に従いますが、マスターに直接マージしないでください。

    git checkout -b fixed-topic <D>
git rebase -i --no-ff <B>
git checkout -b re-merged master
git merge fixed-topic

    これにより、次の結果が得られます。

    re-merged               ––––––––––––––––––––------R
                       /                         /
fixed–topic      C'–––D'                        /
                /                              /
master     A–––B–––E–––F–––G –––&gt; L–––M–––N–––F2
                \     /
topic            C–––D

  2. これで、ツリーが思いどおりにセットアップされました。すべてのファイルが、望みどおりのコンテンツを表示します。1 つの問題は、マージ コミットの親が、実際には元のコミット自体ではなく、元のコミットのリベース コピーであることです。これを修正するのは簡単git-reparentです:

    git reparent -p master -p <D>

    これは次のようになります。

    master     A–––B–––E–––F–––G –––&gt; L–––M–––N–––F2
                \     /                        \
topic            C–––D                          \
                      \                          \
re-merged              ---------------------------R

    注意すべき重要なことは、R の内容は最後のステップから変更されておらず、親だけであるということです。

  3. master を新しいマージ コミットに早送りします。

    git checkout master
git merge re-merged

  4. 最後に、でクリーンアップできます

    git branch -d fixed-topic re-master

終わり！履歴は次のようになり、1 つのブランチが 2 回マージされます。

master  A–––B–––E–––F–––G –––&gt; L–––M–––N–––F2---R
             \     /                           /
topic         C–––D----------------------------
于 2016-05-13T20:50:17.207 に答える
0

「何をマージしようとしても、ここにあるものを保持する」というマージ戦略は、その性質上、元に戻すことはできません。新しいブランチでマージの最初の親をチェックアウトしてから、マージを再度実行します。リベース -- 元のマージの上にある残りのコミットに、これにマージします。

アップデート：

あなたの場合、過去を気にしないのであれば、GN を E にリベースしてから、D をこの新しいマスターにマージするだけです。F は --ours マージだったので、リベースは簡単です。

于 2013-01-09T03:45:09.430 に答える