问题
We are working towards a release: 2 remote feature branches: F2 and F3
How do we deal with F3 to create the release?
- Proposal 1: Simply merge F3 into development.
- Proposal 2: First merge development into F3 (including the F2 changes), then merge into development.
What are the practical differences between these two methods? Is there an objective reason to prefer one over the other?
Blue = Master = Release Branch Red = Development branch Green = Feature branches
回答1:
The outcome is the same, not even a bit differnence on the last 2 commit before 'D'.
But our current workflow is the second one, but it's not a git related choice, it's because we have a lot of automated tests, and more than one release, so we like to run them everywhere where we need to merge the changes.
So basically, since there are no differences in the sources, between 'D', 'f3 head', it's more like a technical choice.
If you choose the second way, you have the opportunity to run tests before f2 merge, f3 merge , and d, but it's only make sense if you use feature branches(f2, f3), since there can be time differences between the merges, and during that time there can be other commits merged into your dev branche(s). In this way, you can test on 'f3 merge' for the two branches, then on merge back to d with all your finised features. But again, it only make sense, if there are commits between f2 merge and d.
If you use dev branches for the iteration(in this case f2, and f3 should be there just to isolating your development, like mostly local branches ), then, your merges from your entire iteration should be merged in and tested together, so there is no need to test on 3 different points.
So basically, the reason behind the second one, is for examle that f3 need the features from f2, and you want to test them together before merging back, to your dev, or if you have multiple releases. So for example not all commits from f2 will be on your dev branch, but you still need to test f2 and f3 together.
It's a tricky question, there is a lot to consider.
But the good news, is even if you change your mind later, or use both strategies git will have no problem with it, so just try them borh, and reevaluate in a fev months.
来源：https://stackoverflow.com/questions/48339550/merging-two-separate-feature-branches-into-the-same-main-branch