0

一体何が起こったのかを追跡するのが難しいいくつかの事例に出くわしました。「開発」ブランチと「マスター」ブランチがあります。新しい変更は「マスター」から取得され、「開発」にマージされます。その後、新しいブランチが「マスター」にマージされます。

過去数週間のどこかで、膨大な一連の変更が開発で取り消されました。それがどのように起こったのか、またはどのように可能であるかはわかりません。とにかく、ファイルの履歴を調べて、それを元に戻したマージを確認できればいいのですが、最後のマージが 1 年前のものであるかのように表示されています。

私がこれを考えることができる唯一の本当の方法は、文字通りコミットハッシュを調べて、それらに頭をリセットし、私がどこにいるのかを確認することです。しかし、それは非現実的なようです。これを行う簡単な方法はありますか?

または、過去のマージを見て、その影響を受けたファイルを確認する方法はありますか? ブランチをマージするときと同様に、どのファイルがどの行で変更されたかの出力が常にコンソールに表示されます..しかし、git ファイルの履歴には、その多くが表示されない場合があります。

また、なぜこれが起こるのか誰にも分かりますか? 私はそれが数回起こるのを見てきました。合流するときにたまに引っかかります。たとえば、新しいブランチを別のブランチにマージすると、最後のコミットで 1 つのファイルだけを変更したことはわかっていますが、他の多くのファイルが変更されます。master ブランチは大規模な一連の更新で約 1 年遅れているため、master からの新しいブランチが作成されて dev にマージされたときに、他のすべてのファイルも切り替えられたと考えています。奇妙ですが、私たちは常にそれを行っており、99% の時間は変更されたファイルのみを変更します。理解できません!

4

1 に答える 1

1

ここで役立つかもしれない git トリックがいくつかあります。

まずgit show <commit hash>、特定のコミットで行われたすべての変更が表示されます。git blame <filename>ファイルが表示され、そのファイルを変更したコミットが行ごとに表示されます。

[コメントに応じて追加]:

git diff <ref1>...<ref2>2 つのコミット間の差の合計が表示されます。マージの場合、これは少し奇妙です。おそらくやりたいことは、git diff HEAD <merge_parent_1>との行に沿って、git diff HEAD <merge_parent_2>各ブランチがテーブルにもたらしたものを確認することです。

最後に、既知の古き良きコミットがある場合 (たとえば、 で見つかったとしますgit show)、 を使用git bisectしてバイナリ検索を実行し、問題が発生したコミットを見つけることができます。

于 2012-04-12T17:45:38.943 に答える