Why does Git show my local "pull from remote" when I push my commit to the remote repo?

Apparently both you and your boss are missing the same thing, and your boss tends towards panic. :-)

Here's what you did, in graphical form drawn as commits. Originally you had this in your repo:

... - F - G    <-- HEAD=master, origin/master

where G is the then-latest version. But there's a typo in one file, so you edited that file in your work-tree, fixing the problem. (I'm going to name the file typo just for convenience below.)

$ vim typo
...

You haven't committed this yet, but you did change it. Then you did:

$ git pull

which got you that error message.

Now, behind the scenes, as it were, git pull is just git fetch followed by git merge. So let's look at what git fetch did. It seems that other developers made four commits; let's draw them into the graphical representation of the commit-tree:

              H - I - J - K      <-- origin/master
            /
... - F - G                      <-- HEAD=master

The git merge failed because someone else modified file typo too.

So, now you do:

$ git add typo
$ git commit -m "reworking to ignore logs"

This adds a new commit on your current branch (whatever HEAD points to), which is obviously master. This gives a commit tree that looks like this:

              H - I - J - K      <-- origin/master
            /
... - F - G ------------- L      <-- HEAD=master

Now you run git pull again, which again is just fetch followed by merge. The fetch has nothing to fetch this time (commits H through K, and the label origin/master, are already all taken care of). The merge then merges commit K (origin/master) into your current branch, master, creating a new merge commit M:

              H - I - J - K      <-- origin/master
            /               \
... - F - G ------------- L - M  <-- HEAD=master

If you now git push the result, commit M goes in, merging your change, L, as the first parent of the merge, and their commit K as the second parent.

That's the actual history of what happened to produce M (as hobbs noted in comment) and is perfectly normal. However, you (and your panicky boss) might prefer to construct a different history, that pretends you noticed the problem in typo after you picked up commits H through K. To do that, you'd "rebase" your commit (L, above) to sit on top of origin/master.

You can do this with git pull --rebase (as in hobbs' answer that appeared while I was typing up this long one), or with plain old git rebase after doing a git fetch. In this case, what you will do is make a copy of the changes in commit L (people often spell this "commit L'"):

              H - I - J - K - L'
            /
... - F - G ------------- L

At this point, you don't need commit L any more—it will stick around in the repo for 90 days or so because of git's "reflogs", but it will vanish from normal git log output, for instance—so you just need to re-draw this graph a bit, leaving out the line going to L, and stick the labels on like so:

              H - I - J - K      <-- origin/master
            /               \
... - F - G                   L' <-- HEAD=master

and this is exactly what the git rebase in the command-sequence:

$ git add typo
$ git commit -m "reworking to ignore logs"
$ git rebase

would have done. (Or, again, you can commit and then use git pull --rebase, which just makes git use the fetch-then-rebase sequence, instead of fetch-then-merge. If there's nothing to fetch, as in this case, that's the same as just running git rebase.)