After looking at your image for even longer, I realized something obvious. Let’s name the commits A to E from bottom to top to make it easier.
So here’s the thing: Before pulling, your local branch was pointing at A
which was the commit you had locally.
When looking at commit D however, you can see that the red line does not end in A
but somewhere before (the screenshot is not showing that). So that commit was not based on A
and as such you could not fast-forward when pulling. You had to create a merge commit instead.
Now you mentioned that you did push A
before, so that’s a bit odd. If you really pushed it and D
was published already, your push would have failed, and you had to merge it first. If D
was not published already, your push would have went through, but then the author of D
would have to merge it before being able to push it.
As you neither of that happened and you had to create a merge later when you pulled, the only reason left would be that you actually never pushed your commit A
.
Note that committing does not automatically push a commit. As I said in the comments, unless you push/pull, everything you do is completely local. And only when you do push or pull, commits are actually transferred to or from the remote.
(The other option would be that the dev pushing D
did get a conflict but chose to force-push instead, removing your commit from the remote repository. If you are using GitHub, this should be visible from that user’s activity log.)