This is a very practical question, but all the answers above are not practical.

Like

git checkout master
git pull origin master
git merge test
git push origin master

This approach has two issues:

1. It's unsafe, because we don't know if there are any conflicts between test branch and master branch.

2. It would "squeeze" all test commits into one merge commit on master; that is to say on master branch, we can't see the all change logs of test branch.

So, when we suspect there would some conflicts, we can have following git operations:

git checkout test
git pull 
git checkout master
git pull
git merge --no-ff --no-commit test

Test merge before commit, avoid a fast-forward commit by --no-ff,

If conflict is encountered, we can run git status to check details about the conflicts and try to solve

git status

Once we solve the conflicts, or if there is no conflict, we commit and push them

git commit -m 'merge test branch'
git push

But this way will lose the changes history logged in test branch, and it would make master branch to be hard for other developers to understand the history of the project.

So the best method is we have to use rebase instead of merge (suppose, when in this time, we have solved the branch conflicts).

Following is one simple sample, for advanced operations, please refer to http://git-scm.com/book/en/v2/Git-Branching-Rebasing

git checkout master
git pull
git checkout test
git pull
git rebase -i master
git checkout master
git merge test

Yep, when you have uppers done, all the Test branch's commits will be moved onto the head of Master branch. The major benefit of rebasing is that you get a linear and much cleaner project history.

The only thing you need to avoid is: never use rebase on public branch, like master branch.

Never do operations like the following:

git checkout master
git rebase -i test

Details for https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing

appendix:

• if you are not sure about rebasing operations, please refer to: https://git-scm.com/book/en/v2/Git-Branching-Rebasing

Let's try to answer this with a couple of general illustrations, since we don't know exactly how your particular case look like. First of all, let's agreeing on how merge and rebase differs, before looking at the case your are asking for, where multiple feature branches based on each other.

As you are probably aware merge preserves history as it happened, while rebase rewrites it. The difference can be seen in above illustration.

Now, let's try to answer your initial question with a similar illustration; where two feature branches (feature-1 & feature-2) are based on each other, and currently trails behind master.

Regardless of how you decide to integrate the changes from master into feature-1 (merge or rebase), feature-2 will be left as is (i.e. without the newly integrated changes from master into feature-1). If you then want to integrate all changes into feature-2 you are once again left with the option of merging or rebasing.

If you would decide to rebase feature-2 onto feature-1 (post the initial master integration) Git would then figure out that commits ol42g and 09qr2 are already present, and hence automatically strip those patches out from your rebased version of feature-2.

A cautionary warning: Rebasing branches that have already been published can cause headaches for your team mates, so make sure to keep a tight dialog if that would be the case. To stay on the safe side, don't rebase branches that are already publicly available.

Hopefully it should be clear now what your options are. =)

If what kind of company would you just not ask your boss for clarification

You should be able to rebase your branch on master:

git checkout feature1
git rebase master

Manage all conflicts that arise. When you get to the commits with the bugfixes (already in master), Git will say that there were no changes and that maybe they were already applied. You then continue the rebase (while skipping the commits already in master) with

git rebase --skip

If you perform a git log on your feature branch, you'll see the bugfix commit appear only once, and in the master portion.

For a more detailed discussion, take a look at the Git book documentation on git rebase (https://git-scm.com/docs/git-rebase) which cover this exact use case.

================ Edit for additional context ====================

This answer was provided specifically for the question asked by @theomega, taking his particular situation into account. Note this part:

I want to prevent [...] commits on my feature branch which have no relation to the feature implementation.

Rebasing his private branch on master is exactly what will yield that result. In contrast, merging master into his branch would precisely do what he specifically does not want to happen: adding a commit that is not related to the feature implementation he is working on via his branch.

To address the users that read the question title, skip over the actual content and context of the question, and then only read the top answer blindly assuming it will always apply to their (different) use case, allow me to elaborate:

• only rebase private branches (i.e. that only exist in your local repository and haven't been shared with others). Rebasing shared branches would "break" the copies other people may have.
• if you want to integrate changes from a branch (whether it's master or another branch) into a branch that is public (e.g. you've pushed the branch to open a pull request, but there are now conflicts with master, and you need to update your branch to resolve those conflicts) you'll need to merge them in (e.g. with git merge master as in @Sven's answer).
• you can also merge branches into your local private branches if that's your preference, but be aware that it will result in "foreign" commits in your branch.

Finally, if you're unhappy with the fact that this answer is not the best fit for your situation even though it was for @theomega, adding a comment below won't be particularly helpful: I don't control which answer is selected, only @theomega does.