私たちの開発プロセスでは、すべての開発者はまず自分のトピック ブランチを master にリベースしてから--no-ffフラグとマージして、マージ バブルを作成する必要があると述べています。これにより、履歴グラフを簡単に追跡できます。ただし、開発者が実際のマージの前にリベースしない Git CLI 経由ではなく、GitHub ユーザー インターフェイス経由で誤ってプル リクエストをマージすることがあり、次のような「乱雑な」履歴グラフが生成されます。
* G
|\
| * F
|/
* E Merge pull request #123 from feature-three
|\
| * D
* | C
|\ \
| |/
|/|
| * B
|/
* A
|\
| * ...
|/
* ...
...
プロセスに従った場合、次の履歴グラフが表示されます。
* G
|\
| * F
|/
* E' Merge branch 'feature-three'
|\
| * D
|/
* C'
|\
| * B
|/
* A
|\
| * ...
|/
* ...
...
(コミットEを変更し、ハッシュが異なるため、プライムに変更していますC)'
のような壊れたマージ コミットのリストをプログラムで取得する必要がありますE。
git rev-list --merges --format='%h %p' A..G | grep -v '^commit'次の出力が生成されます。
G E F
E C D
C A B
最初の列はマージ コミットを表し、2 番目の列は最初の親 (マージ コミットでもあります) で、3 番目の列は 2 番目の親 (トピック ブランチからのコミット) です。ただし、壊れたマージの親関係は問題ないようです。修正された Git 履歴 (2 番目の図) でコマンドを実行すると、同じ出力が得られるため、認識できません。
プロジェクトで壊れたマージ コミットを検出する別の方法が必要です。一部のプロジェクトには 50k 以上のコミットがあり、1 回の実行に 2 秒以上かかるgitため、履歴内のすべてのコミットで実行する必要があるソリューションは好ましくないことに注意してください。git