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

Question

I have a situation like this:

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

Should I merge master i

Answer 1

The most common workflow for handling this situation would probably be to rebase your feature branch on the master branch:

$ git checkout feature-x
$ git rebase master

This gives you:

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

Answer 2

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.