Git Fetch vs Pull: Different Results, Not Sure Why

I usually do a git fetch origin followed by a git merge remotes/origin/master, but was getting a Already up-to-date response. I knew this wasn’t true. A git pull origin worked fine and brought in the changes.

What did I do wrong?

  • Replication service between Git server and users
  • Using git pre-commit hooks in context of GitHub client
  • .gitignore still tracks file even after removing cache
  • How can I preserve sessions when I deploy to Heroku?
  • I updated the branch of a pull request from upstream/master. Will it pollute the pull request if I push the branch again to github?
  • Reference to old commit in Github's issue tracker persits after rewriting history
  • How does SVN store identical text files in different sub-directories
  • git reports merge conflict with no changes, empty lines (using git-subtree)
  • Very large tree: What is wrong with our branch workflow and how to fix it?
  • How to push to remote after a git rebase?
  • Xcode 6: what does “Add to new server” item in “source control: create git repository in …” pulldown mean?
  • git submodule tracking latest
  • One Solution collect form web for “Git Fetch vs Pull: Different Results, Not Sure Why”

    When you did:

    $ git fetch origin
    

    you were not getting the origin/master branch. Assume you were getting origin/other. Then when you did:

    $ git merge remotes/origin/master
    

    because there was nothing new on origin/master (you never fetched it) there was nothing to merge. You got ‘already up-to-date’. As you know, when you did:

    $ git pull origin
    

    there was a merge to perform because ‘pull’ did a fetch (of origin/other) and then a merge (of origin/other). You should be able to see which branches are configured for ‘pull’ and ‘push’ with

    $ git remote show origin
    

    Fix it with:

    $ git checkout master
    $ git branch --track master origin/master
    
    Git Baby is a git and github fan, let's start git clone.