I just stumbled over something peculiar today. I asked a co-worker at my summer job to help me set up a new remote git repo for my code and there was a lot of confusion about wh
None, the repos are copies of each other and pull and push are just direction flows. The difference with your co-worker's method is that he added a 4th unneeded command.
In my view you can either let users push their commits to some repository that's considered to be "the master", or you let them send pull requests to a single user that has permission to modify said "master".
Github, for example, won't let non-contributors push to the repository, but will allow them to send pull requests, so that the contributors can integrate their changes.
Pushing to a remote : send some commits you have to a another git repo. The git repo is considered as "remote", but it can be a repo in another folder of your hard drive. pulling from a remote : get some commits from a remote repo and merge them in your current HEAD (your current checkout of your repo)
Your coworker might have use pull instead of push because your repository might not have been available (no git daemon running, or gitweb, or ssh server on), but his was avalaible from your computer. As it is a server, he might not want to expose a git daemon/service which could be a vector of attack.
But if your repository was shared/available, he would just have been able to do :
Yes, it is working backwards.
Principle workflow is:
One use case (another is explained by Dolanor) for not pushing to remote is that a working copy is checked out on the remote (i.e. it's no bare repo). When he wants to push a branch that is checked out on the remote box (e.g. master:master
), this will not succeed since pushes to checked-out branches are forbidden.
In my opinion, that's the only use case for hopping over to the remote machine and pulling instead of pushing from the local machine.