...
- (master)
git pull - (master)
git commit -m "A" - (master)
git pull(results in a silent, automatic merge commit P1) - (master)
git pull(results in another silent, automatic merge commit P2) - (master)
git commit -m "AB" - (master)
git pull(Yet another merge commit P3) - (master)
git push(The repository master now is identical to his local master)
...
In this graph, Harry's local commits and pull merges appear to have occured in master. Tom's commits (which were always pushed immediately to master) appear to have occured in a separate branch. In a way, this is actually an accurate representation of what has occurred. Harry made some commits in his master branch, merged in changes from a another branch three times, then replaced the repository master with his own.
Development in a local branch
Development in a local branch (even with occasional merges with master) is a valid and recommended development pattern. If parallel commits have been pushed to master in the meantime, this workflow will represent your local changes as if it indeed were a separate branch.
Let us use the same Tom, Dick, & Harry example, except with Harry performing his development in a local, non-published branch. In this example, harry's workflow looks like the following:
- (master)
git pull - (master)
git branch harry_branch origin/master --track - (harry_branch)
git commit -m "A" - (harry_branch)
git pull(results in a silent, automatic merge commit P1) - (harry_branch)
git pull(results in a silent, automatic merge commit P2) - (harry_branch)
git commit -m "B" - (master)
git pull(Is fast-forward. No merge commit created) - (master)
git merge harry_branch(results in an explicit merge commit P3} - (master)
git push(The repository master now is identical to his local master)
As is evident, the github history graph is still complex, but perhaps more "intuitive" in the sense that it preserves the fact that commits 1,2,3,4,5 and 6 had been published in master, and that Harry's commits A and B occurred in some other branch. Harry's pull merges are also preserved - but this time it is clear that changes (commits 4 and 5) were propagated from master into his own branch during the pull/merge, and that he merged his branch back into the published master at the end.