This is a pretty subjective question, but I will give it a pass because I think I can come up with a fairly objective answer.
It’s a great practice to merge master back into your branch before merging it. What if someone else had committed something that broke the feature you just implemented (as you pointed out)? Or what if someone modified the same code you did, and caused possible merge conflicts? I actually suggest merging master back into your branch very frequently. This not only prevents you from having to spend a day and a half resolving merge conflicts (though, that may be a sign that your branches are too large, but that’s another story), but it also keeps you in line as the project changes and evolves.
Some may say that you should rebase your commits on top of master. My short version is: I encourage people to open pull requests very early in the development process, even if a feature isn’t done. This means you’re likely pushing your code to a remote server (such as GitHub). In order to rebase your commits, you would have to push with a rewritten git history, and force push. Force pushing is a poor workflow decision and should be avoided, as it can cause (almost) permanent damage to your commit history.
So yes, merge back from master right before you are looking merge, and as often as you can otherwise. If you use GitHub, I even encourage using the new Protected Branches feature to enforce updating branches with master before merging:
