Git how do I check if there are any changes in another branch

Question

In git, how do I check if there are any changes in another branch (against the current branch)? git fetch origin will show any changes to the current branch in the remote. Is there any way to fetch the same from another branch? git merge origin/master and git rebase origin/master will directly merge from the other branch, if I'm not wrong.

Edit:

My situation is very similar to this. Just that I want to 'check' if I'm required to merge any changes from the master branch before I push my feature branch changes.

Answer 1

The command you want is (probably) git diff. But there is a sort of fundamental mistake in the question itself. Git doesn't store changes and hence there are never any changes in any branch. In fact, the word branch itself is slippery and it's best to talk about commits. Commits don't store changes: commits store snapshots (and metadata).

To compare any two snapshots, one would use git diff. So that's why the answer is (probably) git diff. But you then talk about using git merge and/or git rebase, and these are substantially more complicated.

The git fetch command will obtain, from some other Git repository, any commits that they have, that you don't, that they'd like you to have.¹ So now you have your commits and their commits.

The next trick lies with finding commits. Your commits are, in general, in your branches, but this is using that slippery word branch. To keep this answer short I'm not going to go into detail here, but a branch name in your repository is just your Git's way of remembering the last commit in some series of commits. You can—and almost always do—have commits that come before this last commit. Moreover, each commit can be in more than one branch, and usually the first commit someone ever made is in every branch.

After you use git fetch to get someone else's commits, your Git will create or update a remote-tracking name such as origin/master. This is your Git's way of remembering the commit that their Git, in their repository, has as the last commit on their master. So you can now run:

git diff master origin/master

which will have your Git extract the snapshot from the last commit in your master, then extract the snapshot from the last commit in their master (as remembered by your origin/master), and then compare the two snapshots. The git diff command then gives you a recipe for what changes you could make to the files in your snapshot (master) that, if made to those files, would produce the files they have in their snapshot (origin/master).

You can also run:

git rev-parse master

which will show you the hash ID of the commit that is (currently) the latest one in your own master, and:

git rev-parse origin/master

which will show you the hash ID of the commit that is (currently) the latest one in origin/master—your memory of their master. If these hash IDs are the same, they and you have, or at least had, the same last commit. If they are different, you and they have different commits.²

Whether those different commits hold different snapshots is another question (that git diff will answer). If you and they have the same commit, though, well, that one particular commit has only one snapshot. So git diff won't find any differences, because that one snapshot is the same as itself.

---

¹In general, this is "all commits", although there are specific situations in specific systems where people can hide commits from you, if they want. Mostly, though, you don't need to worry about this. I'm just being careful to be technically correct here by adding the part about that they'd like you to have.

²And, you can now run git diff hash-from-master hash-from-origin/master. The output will match that from git diff master origin/master. The two names are just ways to have Git find the correct hash IDs.