What is the difference between git push and git pull?

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 what he did and what I wanted to do. I asked him to send over his config to be able to see the path to his remote and found out that he didn’t have a remote. When I asked him about this he explained his workflow like this:

  1. Change something locally
  2. Commit
  3. Move to remote dir
  4. git pull c:\localdir

So instead of pushing to a remote he constantly pulled from his local repo to the one on our server. Sort of working backwards. When I confronted him about this he asked me what the difference was and I could not really answer him, but I think there are something right?

  • How to retrieve all object IDs?
  • Github network graph looks like metro map
  • libgit2 returned: Refspec 'refs/heads/origin/HEAD' not found error in TortoiseGit
  • Git is not using the contents of .gitignore
  • How do I “un-revert” a reverted Git commit?
  • Setting umask in Git / Gitolite
  • So my question to you all is: What is the difference in pushing to a remote and pulling from a remote?

  • Dynamic Grunt involving n subdirectories
  • Can I 'git commit' a file and ignore its content changes?
  • git line endings : renormalize does not seem to checkout the right line endings
  • Error When Clone/Push Git Repos 443: Bad access, but no proxy used
  • Removing files from repository while merging makes them disappear
  • Line Ending Problems in GIT
  • 4 Solutions collect form web for “What is the difference between git push and git pull?”

    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 :

    1. change something locally
    2. commit
    3. push to your repository

    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.

    Yes, it is working backwards.

    Principle workflow is:

    1. change something locally
    2. commit
    3. push to remote dir

    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.

    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.

    Git Baby is a git and github fan, let's start git clone.