The default behavior of git pull is git fetch + git merge,
Git pull--rebase is git fetch + git rebase.
For the purpose, there is no difference, and after running, you can get the same code base.
However, from a version management perspective, these two have their own use of meaning.
Git merge:
Simply put, it merges all the commits of two different branch histories into one line and a knot at "end" that generates a merge commit. Finally, a single submission line is formed.
Git rebase:
Depending on the parameters, the behavior is somewhat different. But all in all, it is equivalent to one of the two history of the fork, each submission is picked up and submitted on another submission line. Finally, a single submission line is formed.
In contrast, git merge has one more commit-"merge commit". Git rebase is not.
However, git merge preserves the history of two lines. Git rebase will break the history. Because each time rebase, the commit ID changes (because the parent commit is changed, and the parent commit ID is one of the content used to generate the commit ID).
There is also an article in English:
http://stackoverflow.com/questions/16666089/whats-the-difference-between-git-merge-and-git-rebase/16666418#16666418
