简体   繁体   中英

merging changes from master into a published feature branch

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:

  1. 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.
  2. any developer merges master in whenever they like, no one ever force pushes.

my questions:

  1. am i right that these are the possible workflows?
  2. 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?
  1. Yes.

  2. 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 master to 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

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM