问题
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?
回答1:
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.
回答2:
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)
来源:https://stackoverflow.com/questions/31974891/should-i-merge-master-into-a-feature-branch-to-bring-it-up-to-date-would-this-b