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?

  • What are the differences between git clone --shared and --reference?
  • What is the difference between git revision formats refname@{n} and rev~n
  • How do I properly rebase a git's branch into another?
  • What is the difference between clone and mkdir->cd->init->remote-add->pull?
  • How do you make Git work with IntelliJ?
  • How to create a git commit with date in the past?
  • So my question to you all is: What is the difference in pushing to a remote and pulling from a remote?

  • How can I get faster SSH clone speeds on windows?
  • How to commit in git many files
  • Create a commit using pygit2
  • Remove a folder from Git
  • git upstream is gone after removing remote branch
  • Removing large file from git history?
  • 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.