git pull -u sets the upstream tracking for the branch (or all branches if pushing more than one). Once it is set the tracking persists. There is no reason to use it continually.
–
David CulpJan 5 '13 at 6:26

There isn't much of a difference in the two approaches, but I have noticed sometimes that I don't want to merge the branch into master yet, after merging them, or that there is still more work to be done before these can be merged, so I tend to leave master untouched until final stuff.

There is a sligh drawback on that approach: the actual merge to master is most probably a fast-forward merge and therefore does not create any commit node. This is no problem with the actual code on the branch, but makes it hard to find out later, who did the actual merge to master and at which time. An explicit --no-ff to the merge to master is needed to fix that.
–
michasJan 6 '13 at 7:56

Yes, this is correct, but it looks like a very basic workflow, where you're just buffering changes before they're ready for integration. You should look into more advanced workflows that git supports. You might like the topic branch approach, which lets you work on multiple features in parallel, or the graduation approach which extends your current workflow a bit.