Introduction

When you ask Git for “all files modified in a branch,” the first thing to clarify is compared to what. Git does not store a branch as a separate file list. A branch is just a pointer to a commit, so changed files are always computed relative to another commit, branch, or merge base.

In practice, the most common question is: which files differ between my branch and main? Once that comparison target is clear, the command is straightforward.

The Usual Branch-to-Branch Command

To list file names changed between your current branch and main, use:

git diff --name-only main...HEAD

The triple-dot form matters. It compares HEAD against the merge base with main, which is usually what you want for “changes introduced by this branch.”

If you are currently on the feature branch, this is a good default review command.

Why Triple-Dot Is Often Better

Git supports both double-dot and triple-dot comparisons, and they mean different things.

• 'main..feature compares the end commits directly'
• 'main...feature compares the feature branch against the common ancestor'

For branch review, triple-dot is usually more accurate because it shows what the branch introduced since it diverged.

git diff --name-only main...feature-branch

If you use double-dot carelessly after main has moved forward, you may get a file list that reflects unrelated history differences too.

List Modified Files in the Working Tree

Sometimes the question is not about committed branch history. Sometimes you just want currently changed files in your checkout.

Use:

git status --short

Or only the names of tracked modified files:

git diff --name-only

That shows changes in your working tree relative to the index or HEAD, depending on how you call it.

Include Only Files Changed by Branch Commits

If you want the set of files touched by commits reachable from your branch but not from main, another useful command is:

git diff --name-only $(git merge-base main HEAD) HEAD

This is conceptually similar to triple-dot diff and makes the merge base explicit.

It is especially helpful when you want a scriptable or debuggable formulation of the comparison.

Use git log When You Care About Commit History Too

If you also want to see which commits changed which files, use:

git log --name-only --oneline main...HEAD

This is not just a file list. It is a history view that can help answer a slightly different question: not only what files changed, but which commits touched them.

That is useful during code review or when investigating why a file appears in the diff at all.

Filter for Added, Modified, or Deleted Files

Sometimes you want only certain change types.

git diff --name-only --diff-filter=AM main...HEAD

This example includes only added and modified files, excluding deleted ones.

Useful filters include:

• 'A for added'
• 'M for modified'
• 'D for deleted'
• 'R for renamed'

A Typical Review Workflow

A common branch-review sequence looks like this:

git fetch origin
git checkout feature-branch
git diff --name-only origin/main...HEAD

That ensures you compare against the current remote-tracking branch instead of an outdated local main.

Common Pitfalls

A common mistake is asking for changed files “in a branch” without specifying the comparison target. Git always needs a baseline.

Another mistake is using double-dot when you really want the merge-base view. For feature-branch review, triple-dot is usually the better choice.

Developers also forget to git fetch first, then wonder why the file list differs from what the hosting platform shows in a pull request.

Finally, do not mix up working-tree changes with branch-history changes. git status and git diff main...HEAD answer different questions.

Summary

• Branch file changes are always relative to another commit or branch.
• For “what did this branch change compared to main,” use git diff --name-only main...HEAD.
• Use triple-dot for feature-branch review because it compares from the merge base.
• Use git status or plain git diff --name-only for current local modifications.
• Fetch the latest remote state before comparing if you want results that match code review tools.