Both of these commands are designed to integrate changes from one branch into another branch - they just do it in very different ways.
Consider before merge/rebase:
A <- B <- C [master]
D <- E [branch]
after git merge master:
A <- B <- C
D <- E <- F
after git rebase master:
A <- B <- C <- D <- E
With rebase you say to use another branch as the new base for your work.
When to use:
If you have any doubt, use merge.
The choice for rebase or merge based on what you want your history to look like.
More factors to consider:
Is the branch you are getting changes from shared with other developers outside your team (e.g. open source, public)? If so, don't rebase. Rebase destroys the branch and those developers will have broken/inconsistent repositories unless they use git pull --rebase.
How skilled is your development team? Rebase is a destructive operation. That means, if you do not apply it correctly, you could lose committed work and/or break the consistency of other developer's repositories.
Does the branch itself represent useful information? Some teams use the branch-per-feature model where each branch represents a feature (or bugfix, or sub-feature, etc.) In this model the branch helps identify sets of related commits. In case of branch-per-developer model the branch itself doesn't convey any additional information (the commit already has the author). There would be no harm in rebasing.
Might you want to revert the merge for any reason? Reverting (as in undoing) a rebase is considerably difficult and/or impossible (if the rebase had conflicts) compared