この回答を明確にするために、いくつかの定義とメモから始めましょう。
- マージを実行するには、git は「マージ ベース」を見つける必要があります。これは (非常に大まかに) 「現在のブランチとマージされるブランチが開発履歴を共有するコミット」です。
- あなたは現在マージを行っており
--no-commit
、マージの競合を使用しているか、取得しています。後者の場合、これらの競合はまだ解決されていません。
- したがって、作業ツリーにはコミットする準備ができているファイルがありますが、実際にはコミットしていません。
- 一度コミットされたマージには、2 つの親コミットがあります。1 つは、マージ コミットを行う直前にいたブランチの先端であったコミットです。まだマージ コミットを行っていないため、現在の
HEAD
コミットがこのブランチの先端になります。したがって、以下の「コミット」というフレーズは、HEAD
「マージを行う前のブランチの先端」を意味します。
- 一方、マージされるブランチ (2 番目の親になる) からのコミットには、短い単語またはフレーズも必要です。これを「インバウンド」コミットと呼びます。(この用語は他では見たことがありません。いくつかのシソーラス エントリを調べた後に作成したものです。)
あなたのコメント返信に基づいて、コミットから変更されたファイル、つまり、インバウンド コミットから変更を取得したファイルを見つけたいと考えています。HEAD
これが正しければ、答えは非常に簡単です。
git diff --cached --name-only
それらをリストします。(これは、マージされていないファイルが表示されないため、少し驚きです。git diff --cached
)--name-only
git が正常にマージされた (またはマージされたと思われる) ファイルのみが必要な場合は、次のようにします。
git status --porcelain | awk '/^M / { print $2 }'
それらをリストします。( を省略し、必要に応じて の代わりにまたはをawk
使用して、 からの出力を表示します。この場合、状態が「マージ済み、コミット準備完了」であるファイルを探します。マージ競合のあるファイルは状態になります。)-s
--short
--porcelain
git status
M
ファイルをそのマージ ベース バージョンと比較することもできます。これは、複数のマージベースの (ややまれな) ケースを除いて、それほど難しくありません。ただし、これらの詳細はこの回答から除外します。