First, remember that when you run git push (or, for that matter, git fetch), there are two Gits and two repositories involved in the process. One is "your" Git and "your" repository, and the other is the remote's Git and its repository. (The repository at the remote may belong to you as well, but just think of it as some other person, taking requests from you, over an Internet-phone-call.)
Messages printed without remote: in front of them are coming from your Git. Messages printed with remote: in front are coming from the remote. They're not coming directly from the other Git—the two Gits have their Internet-phone arrangement set up so that they talk directly and know what each other is saying—but rather, from something run by the other Git. When the other Git runs things—such as hooks—and those things print their own messages, their Git copies those messages across to your Git, saying to your Git: "I don't know what this means, but the hook printed this, and it might be important, so why don't you show this to the only human being available in ths whole process, i.e., the person doing the git push?" And your Git does: it prints remote: whatever to indicate that something the other Git ran printed whatever.
Now, in your setup, you have a deployment script set up on the other system. That's your post-receive hook. A post-receive hook can do many things, but your particular script is intended as a deployment mechanism. You put approximate contents of this script up in a comment, but here it is better-formatted (comments do not support formatting):
#!/bin/sh
GIT_WORK_TREE=********************
export GIT_WORK_TREE
git checkout master
What this script does is make the otherwise bare repository—the one on the remote—act as a non-bare repository: the work tree is specified through GIT_WORK_TREE. (Incidentally, you could make this a one line script, instead of three lines: git --work-tree=... checkout master. There's no particular reason to prefer either form here other than personal taste, though.)
What kind of output does git checkout sometimes print? Well, let's try it:
$ git checkout master
M wt-status.c
Already on 'master'
What did you see in your output, prefixed with remote:?
remote: Already on 'master'
remote: M app/Http/routes.php
Conclusion: this is almost certainly coming from the git checkout command your deployment script runs. (The order of the two lines has changed, but they're still from the git checkout.)
When does git checkout print this kind of message? Git's documentation is a bit thin here, but:
To prepare for working on <branch>, switch to it by updating the
index and the files in the working tree, and by pointing HEAD at
the branch. Local modifications to the files in the working tree
are kept, so that they can be committed to the <branch>.
Thus, this occurs when the index and/or work-tree are modified, but those local modifications can be kept. (See Git - checkout another branch when there are uncommitted changes on the current branch for details.)
This means that your (remote) work-tree has some change made to file app/Http/routes.php, with respect to the HEAD commit.1 When you, with your Git, push to the remote, with its Git, the remote Git runs the deployment script. When the deployment script uses your undisclosed work-tree along with the bare repository to make it act like a non-bare repository, and the other Git's deployment script runs git checkout, that checkout "keeps the (local-to-remote-work-tree) modification", but prints that M line.
Since the modification being kept is on the remote, the only way to deal with it is to go to the remote (e.g., ssh in) so that you can work locally there. Then, investigate why that work-tree is modified: Who made this change? Why? What does it do? Should it be in the repository? Should it be done some other way? Do you need to modify the deployment script? I cannot answer any of these questions for you; you must decide how to make this all work.
1Slightly complicating the picture, these could be in the remote's index. This index is in fact the bare repository's index, because git --work-tree=... checkout uses the (single) index from the repository, even though that index reflects the work-tree. Chances are, however, that the change is only in the deployment work-tree over on the remote.
