ブランチ 'X'を 'Y'にマージします。ここで 'X'は既に 'Y'の復帰コミットコミットを持っています。

Question

さて、誤って 'Y'を 'X'にマージしてプッシュしました。これは間違いだったので、コミットを元に戻しました。すべていいよ

私は 'X'の最新の変更を 'Y'にマージしたいのですが、gitはファイルの束を表示しています。それらは復帰コミットでブランチ「X」から削除されましたが、「Y」にまだ存在するはずです

Answer 1

マージを元に戻すと、ほとんど常に予期せぬ結果になります。gitはそれを効果的に解釈します支店の変更はとなることはありませんする必要があります。問題は、GitはWがMによってmasterに導入された変更を「取り消し」

O --- x --- x --- M --- W --- x --- x <--(master) 
\    /
    A ---- B ---- C --- D --- E <--(branch) 

を見ているということです。 branchをmasterにマージすると、マージベースはCになります。つまり、gitはAからCまではmasterで既にMであると考えていますので、マージベースとしてOに戻る必要はないと思います。

多くの理由がありますが、revertが最善の解決策である可能性がありますが、それは余分な作業を必要とする可能性があります。

最も簡単な手順は、masterのWを元に戻し、branchをマージすることです。

O --- x --- x --- M - W - x - x - M' - M2 <--(master) 
\    /    /
    A ---- B ---- C ------- D -------- E <--(branch) 

は、私はこのことについては好きではないことを妨げる可能性が壊れた状態になりますかなり良いチャンスM'、があることで、将来のバグ狩り（あなたがbisectを使用している場合など）。一部の人々はまた、私はその懸念に個人的に多くの重量を置いていないが、それは "醜い"に見えると思う。

M'とM2を一緒に「スカッシュ」し、取得しようと思ったマージを再現したいように思えるかもしれません。これは審美的に魅力的な継ぎ目をつけるかもしれませんが、それは "悪い合併"を作ります。それは、親との相対的なパッチが想定されていないマージです。それだけでは簡単ではありません（決して不可能ではありません）。 〜Eによって最初に導入された変更を再導入する1つまたは複数の新しいコミットを作成することです。基本的に、変更が「考慮されている」ことを「忘れる」ようになります。

git rebase -f O branch 

（ここで、上流としてmasterを使用することはできません;あなたはおそらく、それはSHA IDです与えることで、上流はOコミットであることを指定する必要があります）

A' --- B' --- C' --- D' --- E' <--(branch) 
/
O --- x --- x --- M --- W --- x --- x <--(master) 
\    /
    A ---- B ---- C 

ここからbranchをmasterに単純にマージすると、期待どおりに動作します。

Answer 2

復帰を元に戻し、XをYにマージしてください。元に戻したくない場合は、その場合、X（Z）から新しいブランチを作成し、Zを元に戻してZをYにマージします。