The major hurdle I had in trying to understand the merge vs rebase argument was that it is not immediately apparent that the git pull command is actually a shorthand for two separate commands, ‘git fetch’ and ‘git merge’.
git pull origin production
Does two things. It fetches the HEAD of the production branch and brings it down into your local repository. At this point it has not altered your local branch in anyway. Secondly it performs a merge which will replay any changes to the remote (which may be several commits ahead) over your local branch. The crucial point to understand here is that these changes will replayed over your local branch at it’s current state.
git pull --rebase origin production
Is equivalent to ‘git fetch && git rebase origin production’. Using pull in this way will conversely to the above, take the most recent common ancestor between your local branch and the remote, fast forward your local branch to the remote HEAD and then replay your commits over the top.
In either case the resulting code should be identical and you will still need to push your changes back to the main trunk. The main difference is in the way your repositories history will look. Using the rebase method, it is arguably easier to see journey your repository makes, with each sequential story having a dedicated commit message containing the entire history of the branch.