Git Workflow Pull vs Fetch

Question

I know this question has been asked before but it seems to me that the answer has been changed with time so I'm quite confused. So once and for all in 2012 december 22 after domesday, (those of us that survived) what is the recommended way of working with git when you want to pull in the latest change from remote branch say "develop".

I use pull and to be honest never used fetch. I just feel alarmed that I might be getting my self in to some strange situation done the line.

Here is an example of my workflow:

git pull origin develop
git checkout -b story-001
...do some work
git commit -am "fixed utests"
.. do some more work
git commit -am "fixed impl for service x"
git rebase develop
git checkout develop
git merge --squash story-001
git commit -m "Story 001 completed <testinfo>"
git push origin develop
..error.. master is head..
git pull origin develop
..maybe merge issue
git mergetool
..resolved problem
git commit -am "resolved merge for story 001"
git push origin develop
git branch -D story-001
....
... and so on
... after a while some changes on remote <develop>
... 
git pull origin develop

As you see no fetch in my world, why should there be?

Answer 1

Well, git pull does git fetch followed by git merge . So, if you wish to automatically merge the pull ed repository, then you have no need for git fetch .

Answer 2

If you want your current (local) work stay on top you do

git fetch
git rebase origin/develop

or

git pull --rebase

Merging in the code ie pull when remote and local has changed, can have the effect that your local work is placed in the wrong order and is overwritten by remote changes.

So if you want to just grab the remote you should do pull and fetch if you have done some work on your local. Just to keep it simple. But most of time the pull will work if you are lucky.

This is what I have understood by doing some more research. However I'm not sure until I try a little experiment to verify.

I think the best solution is to use git pull --rebase most of the time, makes more sense somehow. You could change the default behavior of git pull as I understand it but that can be dangerous as you might forget about it and confuse yourself even more.

Answer 3

I usually work like this:

git pull origin develop
git checkout -b story-001
git commit -am "..."
# more commits, squash the commits, reorganize

While at this stage, I often do git fetch to get the latest changes. If there are any new changes, I will do git rebase origin/develop to move my work on the feature branch on top of the new changes.

# work some more
git checkout develop
git merge # defaults to origin
git merge story-001
git push

With this workflow, I have no merge commits, the history is pretty clean. Also I don't usually write these commands, try something like git-smart .