Should I merge master into a feature branch to bring it up to date? Would this be considered bad practice?

I have a situation like this:

            (master)
A - B - E - F
      \       
        C - D
            (feature-x)

Should I merge master into feature-x if I need critical fixes E and F into the feature-x branch to continue development and I intend to merge back into master?

Is there any disadvantage to repeated merging master into a feature branch and then the feature back into master when the feature branch might or might not be shared with other developers?

Solution

So far as I understand, merging master into your feature branch isn't considered bad practice. @larsks answer gives some good info about how to use rebasing which is an option. But be sure to follow the golden rule "Do not rebase commits that exist outside your repository"(see Perils of rebasing).

To clarify: 'commits that exist outside your repository' would be public (pushed) commits.

If you wonder whether rebasing, is better than merging or vise versa, I would suggest you look over: 'Rebase vs. Merge'. The article points out that the answer to this is dependent on what you and your team think is best for your project.

For larger projects, I like the history to show exactly what happened. So where I work, we usually merge master into our feature branches to get them up to date with the latest code. Though, I wouldn't necessarily consider this a global best practice for everyone. However, it's not considered bad practice either.

Some others like to have very clean history, so for them rebasing may be considered the better option.