すでにマージされたブランチを再マージするには？

Question

以下のようなコミットグラフがあります。 *とマークされたコミットは、多くのコミットを表します。

A* 
    | 
    B--------- 
    |  | 
    C*  D* <- old feature branch 
    |  | 
    E--------- 
    | 
    F* 
    | 
    G  <- master 

マージコミットEが正しく行われず、C *の一部の変更（すべてではない）が失われました。このマージをやり直して、現在のマスターに変更を再導入するにはどうすればよいですか？

すべてがすでにプッシュされています（オープンソースプロジェクト）ので、履歴の変更はオプションではありません。

私はコミットのC *からパッチを作成しようとしたマスターにそれを適用されますが、C *からの変更の一部が正しくマージされているので、それがコミットするので、プロジェクトが進化しているため、約80％パッチは失敗します。

理想的には、C *のすべての変更を適用し、それらを適用してすべての競合を解決します。しかし、ブランチはすでにマージされているので、gitは変更を検出せず、再度マージすることもできません。

$ git checkout 5bc5295 # C 
HEAD is now at 5bc5295... cleanup 

$ git checkout -b "missing-commits" 
Switched to a new branch 'missing-commits' 

$ git checkout master 
Switched to branch 'master' 
Your branch is up-to-date with 'origin/master'. 

$ git merge missing-commits 
Already up-to-date. 

Answer 1

理想的には、C *のすべての変更を適用して、それらを適用してすべての競合を解決します。

いいえ、理想的にあなたが時間を巻き戻しますが、それは（が、正しくこの時間）当時あったようにマージを行う、そしてF*変更を再適用し、正しいmasterで終わります。

あなたはこのようにそれを行うことができます：あなたはリベース中にすべての競合を処理するために管理する場合

git checkout missing-commits 
git checkout -b correct-merge 
git merge D # do it right, this time around! 
git checkout master 
git checkout -b correct-master 
git rebase --onto correct-merge wrong-merge correct-master # have fun with the mother of all rebases! 

を、あなたは枝correct-masterで、もともとは、あなたが望んでいた正確に何で終わるだろう。

あなたは歴史を変更したくないので、あなたはその後、大きなパッチを作成することができますし、あなたの現在のmasterにそれを適用しますが、私は、このアプローチは、より多くの（あなたの作業ディレクトリyourreposにすべての仕事をしたと仮定して）好き：

今

cd yourrepos ; git checkout correct-master ; cd .. 
cp -a yourrepos newrepos 
rm -rf newrepos/.git 
cd yourrepos ; git checkout master ; cd .. 
cp -a yourrepos/.git newrepos/ 

、あなたがnewreposを入力してgit statusを行うとき、あなたは枝masterになり、パッチを適用したかのように、masterとcorrect-masterの間で正確にすべての変更が表示されます。削除されたファイル、新しいファイル、変更されたファイル、変更されたアクセス許可、変更されたシンボリックリンクなどをキャッチします。

理想的には、すべてが正しく行われた場合、正確には、失われたコミットをCから正確に表示します。 git addのお気に入りのバリアントを使用し、最終的にはgit commit（または複数の場合もあります）を使用すると、完了です。履歴は書き換えられていません。

Answer 2

は無地のパッチを作成し、git format-patchとgit amを使用するためにそれらを適用するのではなく、試してみてください。これにより、アプリケーションがただ失敗するgit applyとは異なり、マージツールを使用して競合を解決できる通常の競合状態が発生します。

Answer 3

あなたはチェリーピックで試すことができます：コミットが祖先であるため、

git checkout master 
git cherry-pick B..[last_commit_of_C*] 

Gitはチェリーピックを確認するように依頼することがあります。

Answer 4

Gitはスナップショットを保存してその場で変更を検出するので、悪いコミットと良いものの違いを処理する方法は、子孫として何かと同じように悪いものを記録することですそれを考えてください。正しい家系gitの言うことgit reset --softを使用します。

git checkout badmerge^1 # generate the right result 
git merge badmerge^2 

git reset --soft badmerge # as an improvement on the wrong result 
git commit 

git checkout master  # merge the difference now that git sees it 
git merge @{1} -m "applying corrections to a bad merge"