You can either git merge master or git rebase master.
If the branch has not been distributed to other people, in this case i would prefer git rebase.
Because git rebase makes it as if the changes on the feature branch were made on top of the changes on the master branch, which makes the version graph simpler.
Rebase
Taking the example from the git rebase manual, git rebase master in branch feature:
A---B---C feature A'--B'--C' feature
/ --rebase--> /
D---E---F---G master D---E---F---G master
However, git rebase is only suitable when nobody else is working on it, or there will be confusion and extra work for them, because the old commits A, B, C are now replaced by new commits A', B', C', plus F and G that were not there before.
The actual result after git rebase master in branch feature is this:
( A---B---C ) feature@{1}
/
/ A'--B'--C' feature
/ /
D---E---F---G master
Commits A, B, C are dangling after the rebase, but are reachable through git reflog feature as feature@{1}.
Merge
If someone has pulled your branch, or you have pushed it somewhere, you should merge into it instead, to avoid confusion and extra work on the other end. See Recovering from upstream rebase.
This is the result of git merge master in branch feature:
A---B---C feature A---B---C---M feature
/ --merge--> / ,---’
D---E---F---G master D---E---F---G master
Alternatively, if you git merge feature in branch master, it would look like this:
A---B---C feature A---B---C feature
/ --merge--> / \
D---E---F---G master D---E---F---G---M master