These are coming in where other developers are pulling down changes from remote, into their local repo, before they push their changes back into remote (I think, clarification would be great if not).

That’s absolutely correct.

I just wanted to check that it’s expected to see these messages in the remote,

It’s perfectly normal. If they’re very noisy, alternatives are:

1. use git pull --rebase (you can configure this as the default behaviour) instead. This means everyone’s local changes are always (re)based onto the remote branch HEAD, and pushes are always fast-forward.

   You do have to be comfortable with fixing the rebase if it doesn’t apply cleanly though, and with commits showing up out of time order

2. work on feature branches and merge less frequently

Since git is (in my opinion, and maybe everyone else’s) more complicated than SVN, answering this single question will do you more harm than good. Sounds like you didn’t spend time on learning the fundamentals.

I suggest you (and your entire team) read the great, well written tutorials by Atlassian (go to the ‘getting started’ section). I read them after some time of just winging it with git after migrating from svn, and I can’t stress enough how important it is to actually sit down and read about how things work there:

https://www.atlassian.com/git/tutorials/

Having the merge commits and seeing the merge commits are really different things.

If you only are concerned with reporting, you can use arguments to the git log command.

Having two parents is why they exist.

The workflow is ‘correct’ in that it is not technically a problem. But your workflow may change as you become more familiar with the git toolset. And then you may change your workflow to something more ‘correct’ for you.