Categories
branch git git-branch git-diff

Showing which files have changed between two revisions

2278

I want to merge two branches that have been separated for a while and wanted to know which files have been modified.

Came across this link: http://linux.yyz.us/git-howto.html which was quite useful.

The tools to compare branches I’ve come across are:

  • git diff master..branch
  • git log master..branch
  • git shortlog master..branch

Was wondering if there’s something like “git status master..branch” to only see those files that are different between the two branches.

Without creating a new tool, I think this is the closest you can get to do that now (which of course will show repeats if a file was modified more than once):

  • git diff master..branch | grep "^diff"

Was wondering if there’s something I missed…

7

  • 20

    How many others find the title of this question misleading? It is actually about finding the file differences between two branches. What I came here looking for was how to see file differences between two revisions on the same branch. Or am I the only one?

    Mar 18, 2016 at 10:19

  • 5

    @SandeepanNath: with git there is no difference. You are ALWAYS referring to individual commits.

    Mar 21, 2016 at 2:54

  • @SamuelO’Malley I am new to git and considering the seemingly common branching strategy wherein all the branches are finally merged to the master branch and ultimately the master is rolled out. Now, considering the event of a rollout, where the production is already at master, but behind the tip (by one revision if the last rollout happened after the last master merge), I would like to see the differences between these two revisions, to find out what would be rolled out. I would not like to look at the branch which was last merged. Correct me if I am wrong.

    Mar 21, 2016 at 6:22


  • 2

    @SandeepanNath: instead of using the branch names then you can take the answers below and just specify the commit IDs instead. Or even refer the commits by their tag names if you create tags when rolling out.

    Mar 21, 2016 at 6:50

  • 2

    @SandeepanNath You cannot compare 2 branches, you must specify the revision. So comparing 2 branches is comparing 2 revisions.

    Dec 15, 2017 at 15:37

2797

To compare the current branch against main branch:

$ git diff --name-status main

To compare any two branches:

$ git diff --name-status firstbranch..yourBranchName

There is more options to git diff in the official documentation (and specifically --name-status option).

14

  • 4

    What’s do each of the indices on the left hand side mean (I see a lot of M’s and D’s)?

    Apr 5, 2013 at 18:25

  • 24

    @user446936 – you can see what the letters mean in the git status man page @ kernel.org/pub/software/scm/git/docs/git-status.html – in particular, M == modified, D == deleted

    Apr 11, 2013 at 18:34

  • 12

    git diff --name-status your_branch...master outputs the changes that occurred on master since your_branch was created from it

    – Radu

    Aug 20, 2013 at 10:38


  • 1

    The double-dot operator is superfluous, here, because diffs are pairwise.

    – jub0bs

    Sep 7, 2015 at 11:54

  • 3

    I get unknown revision or path not in the working tree.

    Oct 15, 2015 at 14:18

433

Try

$ git diff --stat --color master..branchName

This will give you more info about each change, while still using the same number of lines.

You can also flip the branches to get an even clearer picture of the difference if you were to merge the other way:

$ git diff --stat --color branchName..master

4

  • 80

    If you have (highly recommended, imho) git color turned on (config --global color.ui true), you can skip the –color. (I have lks – lazy keyboard syndrome.)

    – Art Swri

    Mar 10, 2012 at 21:35

  • 28

    I’m with you on color! BTW I meant to say git config --global color.ui true – to be complete.

    – Art Swri

    Mar 10, 2012 at 22:13

  • 3

    Does not work, throws errors: fatal: ambiguous argument 'master..branchName': unknown revision or path not in the working tree.

    Jan 18, 2017 at 15:15

  • 7

    @TomášZato sorry but you need to swap “branchName” with the name of your branch.

    – Gerry

    Jan 30, 2017 at 12:01

171

Also keep in mind that git has cheap and easy branching. If I think a merge could be problematic I create a branch for the merge. So if master has the changes I want to merge in and ba is my branch that needs the code from master I might do the following:

git checkout ba
git checkout -b ba-merge
git merge master
.... review new code and fix conflicts....
git commit
git checkout ba
git merge ba-merge
git branch -d ba-merge
git merge master

End result is that I got to try out the merge on a throw-away branch before screwing with my branch. If I get my self tangled up I can just delete the ba-merge branch and start over.

8

  • 5

    Awesome. I have never thought of branching that way. I think this should be considered as part of the “best practices” when merging.

    – egelev

    Jul 1, 2015 at 14:08

  • When you merge the ba-marge back into ba, isn’t there a potential to have to fix the conflicts again?

    – Josef.B

    May 2, 2017 at 2:48

  • 2

    @EricAnderson Right, it’s a graph. SVN sticks like gum under a school desk. thx.

    – Josef.B

    May 2, 2017 at 4:10

  • 1

    Why do you need to do last step ‘git merge master’ if ba-merge already had master

    – qwebek

    Sep 4, 2018 at 14:30

  • 2

    @EricAnderson why would you need a throw away branch if something failed during merge? Isn’t just cancelling the merge changes be enough? Something like, git reset --hard; git clean -fd ?

    – nawfal

    Oct 18, 2018 at 18:19