If there are multiple developers working on a feature branch, and we need to periodically bring in changes from master, there are two approaches that I know of:
- developers communicate that they have the latest changes from the published feature branch. Then one developer rebases onto master and force pushes. Other developers pull down the new feature branch and everyone continues developing.
- any developer merges master in whenever they like, no one ever force pushes.
my questions:
- am i right that these are the possible workflows?
- with the second workflow, when it's time to bring the feature branch into master, how can this be done with the cleanest history possible? Will a rebase onto master clean up/remove the other merge commits, or will it be a mess?
VonC
Yes.
yes, unless you rebase with the --preserve-merge option, those merge commit would still be there, but without any parent on
master.
I tend to favor the first approach because:
- it does enforce communication within the dev team
- it avoids "back-merge" (from
masterto a feature branch) - it doesn't require those merge commit from master that you would want to keep during a final rebase.
- it facilitates the final integration of that feature branch into master
来源：https://stackoverflow.com/questions/19337557/merging-changes-from-master-into-a-published-feature-branch