4

私はマスターからのブランチを持つgitリポジトリに取り組んでいます。これをabブランチと呼びます。私のチームはブランチに取り組んでおり、abgithubを使用したプルリクエストワークフローを持っています。私のチームメートの1人が、自分のブランチjeremy_ab_deletionsからブランチへのプルリクエストを行いましたab。私は彼の変更を確認/テストしていましたが、abブランチにマージしようとしたときに、誤ってマスターにマージし、間違いを見つける前にマスターをgithubにプッシュしました。私が行った変更をgit-revertできると思っていたのですがgit revert SHA、うまくいったようです...

それで十分だと思い、喜んでabブランチに戻って作業を続けました。しかし今、私は、決してabマスターになるべきではないブランチからの以前のコミットがすべてマスターにあることに気づきました。それは...かなり混乱しています。彼のブランチは元々から分割されていたので、それをマスターにマージしたので、を使用して元に戻す必要がありました。abgit revert -m 1 SHA

今日、私はどこが間違っていたのかを正確に把握しようとしていましたが、gitの履歴とreflogに基づいて、あらゆる種類の混乱が生じています。最初に、私は元に戻すことを試みました、そして次にしますgit revert -m 1 SHAしかしgitは私に言います：

fatal: Mainline was specified but commit 4c431c345dfe0a856967c090932c32f153824085 is not a merge.

だから私は大丈夫だと思います...多分それはマージコミットではなく、私は別のSHAをターゲットにする必要があります。しかし、歴史を見ると、私は一生の間、これらのどれがマージコミットであったかを理解することはできません...

This was supposed to be on AB... 
…
d985b5bcf8 Browse code
Nathan B authored 8 days ago

This was supposed to be on AB... 
…
0e01911273 Browse code
Nathan B authored 8 days ago

removed unecessary tests
4c431c345d Browse code
Nathan B authored 8 days ago
Apr 17, 2012

removing un-used views and pages
a546f90ed3 Browse code
jeremychurch authored 10 days ago

「これはABにあるはずだった」という2つのコミットは、「削除された不要なテスト」と「未使用のビューとページの削除」コミットを元に戻すための元に戻すコミットです。マスターへの次のコミットは今日で、それ以前のコミットは16日で、どちらも関連していませんでした。実際のマージがどこで発生したかわかりません。

私はreflogを調べて、正確にすべてが台無しになっている場所を確認しました。キーファイルを使用してreflogバージョンを上下に移動し、git reset --hard HEAD@{NUM}キーファイルを調べて、悪い変更がまだその場所にあるかどうかを確認しました。最後に、これらのreflogに絞り込みました。

1fe2be2 HEAD@{79}: checkout: moving from 1fe2be29c6eda9f9fc9eb0b372ee83b7c15dfc2c to jeremy_ab_deletions
1fe2be2 HEAD@{80}: HEAD@{3}: updating HEAD
4c431c3 HEAD@{81}: HEAD@{1}: updating HEAD
47a97af HEAD@{82}: commit: removed unecessary tests, routes, and controller actions
4c431c3 HEAD@{83}: merge jeremy_ab_deletions: Fast-forward
1fe2be2 HEAD@{84}: checkout: moving from master to ab
d985b5b HEAD@{85}: revert: This was supposed to be on AB...
0e01911 HEAD@{86}: revert: This was supposed to be on AB...
4c431c3 HEAD@{87}: merge jeremy_ab_deletions: Fast-forward
c121a08 HEAD@{88}: checkout: moving from jeremy_ab_deletions to master
4c431c3 HEAD@{89}: commit: removed unecessary tests
a546f90 HEAD@{90}: checkout: moving from ab_page_changes to jeremy_ab_deletions
511b340 HEAD@{91}: checkout: moving from jeremy_ab_deletions to ab_page_changes
a546f90 HEAD@{92}: pull git@github.com:REDACTED/repo.git ab-remove-stuff: Fast-forward

具体的には、ここのHEAD @ {88}には不正なコミットがなく、HEAD@{87}には不正なコミットがあります。したがって、私がコミットで失敗したと仮定するのは合理的ですmerge jeremy_ab_deletions: Fast-forward......しかし、それがどの「マージコミット」であるかを理解することはできません。私はこれを試しました：

$ git revert -m 1 4c431c3
fatal: Mainline was specified but commit 4c431c345dfe0a856967c090932c32f153824085 is not a merge.

私は...実際のマージコミットが見つからないようですか？誰かが私が間違ったことを知っていますか：/私は今あらゆる種類の道に迷っています。

4

2 に答える 2

4

他の誰もこのマスターを引っ張っていない場合（または引っ張ったが、確かにそれを使用していない場合）、これは私がすることです：

  1. 'accident'以降にマスターで作業が行われなかった場合は、最後の適切なコミットにリセットしてから、リモートマスターブランチを更新します（-fを押して）。
  2. いくつかの作業が完了した場合は、それを最後の適切なコミットにリセットしてから、git rebase -i問題のあるコミットを使用および削除して、適切なコミットをリストに残すことができます。次に、（を使用して）を押す必要があります-f。

または、新しいブランチでこれをすべて行うことができます。

  1. マスターで最後の適切なコミットをチェックアウトし、そこにブランチを作成し、
  2. 次に、を使用git rebase -i masterして不正なコミットを除外します。
  3. 次に、マスターに戻って手動で「マージ」し、新しいブランチからすべての変更を取り込み、マスター内のすべてを上書きすることができます（とを使用でき--no-commitますgit checkout --theirs）
  4. 固定マスターを（なしで ）プッシュします。-f

お役に立てれば！私は緊急事態が嫌いです。

于 2012-04-27T18:44:30.810 に答える
1

更新：これは他の誰かを助けるかもしれませんが、これは実際に私にとって物事をより苛立たせました。他の誰かがそれに遭遇した場合に備えて、これをここに保持します。

sinelawは私を正しい方向に向けました...しかし、私はここでより適切な答えを見つけました： GitのSHAハッシュによるコミットに戻りますか？

回答のメッセージは次のとおりです。

別のコミットで正確な状態で現在のHEADの上にコミットし、すべての中間コミットを元に戻したい場合は、resetを使用して、コミットを行うためのインデックスの正しい状態を作成できます。

これはまさに私が欲しかったものです。HEAD @ {88}に戻したいのですが、一部の人はすでにマスターブランチをプルしていて、リセット手順を実行する必要がないので、それを独自のコミットに戻します...だからこれらは私が使用したコマンドです：

# reset the index to the desired tree
git reset HEAD@{88}

# move the branch pointer back to the previous HEAD
git reset --soft HEAD@{1}

git commit -m "Revert the bad ab merge"

# Update working copy to reflect the new commit
git reset --hard

# Clean untracked files
git clean -f -d

履歴を見ると、abブランチ専用であるはずのすべての変更を正確に逆にしてコミットを作成したことがわかります。

（更新）：気にしないでください、これは私が望んでいたものではありません。私たちのリポジトリには、「マスター」ブランチだけでなく、いくつかのブランチがあります。マスターは、他の3つのブランチ間で普遍的な変更を保持することを目的としており、これらのブランチに頻繁にマージされます。このrevert-with-a-commitの一連のコマンドを実行すると、マスターが「ab」ブランチ（またはその場合は任意のブランチ）にマージされるため、マージの競合と意図しない削除されたファイルの深刻な悪夢が発生しました（abに存在する必要があるため） 、マスターではありません）。私は上記のsinelawのソリューションを使用し、マスターを引っ張って良いバージョンに戻した1人の技術者ではないデザイナーと協力しました。

于 2012-04-27T19:50:55.980 に答える