In the context of a revision list, A...B is how git-rev-parse defines it. git-log takes a revision list. git-diff does not take a list of revisions - it takes one or two revisions, and has defined the A...B syntax to mean how it's defined in the git-diff manpage. If git-diff did not explicitly define A...B, then that syntax would be invalid. Note that the git-rev-parse manpage describes A...B in the "Specifying Ranges" section, and everything in that section is only valid in situations where a revision range is valid (i.e. when a revision list is desired).

To get a log containing just x, y, and z, try git log HEAD..branch (two dots, not three). This is identical to git log branch --not HEAD, and means all commits on branch that aren't on HEAD.

An alternative to the answer by @Marco Ponti, and avoiding the checkout:

git diff --name-only <notMainDev> $(git merge-base <notMainDev> <mainDev>)

If your particular shell doesn't understand the $() construct, use back-ticks instead.

For current branch you can use:

git diff --name-only $(git merge-base <mainDev> HEAD)

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.