What would be the preferred way to achieve the following workflow with either Git
or Subversion
(I have more interest in the Git
version, but comparison will definitely be useful):
Let's say we had a major release of the product recently and there is a specific polisihin branch called
release-2.0.x
.The development then continued and several feature branches were merged into the
master/trunk
(they will later become the part of the upcomingrelease-2.1.x
).Now, at some point another feature (namely,
critical-feature
) was developed and merged back tomaster/trunk
. We realize that this feature is so important, that we have to backport it torelease-2.0.x
.
Here is a small pseudographic illustration for the described case. Note that everything on the top brings in tree differences between release-2.0.x
and current master/trunk
and leads to merging problems (otherwise I could simply merge the critical-feature
and avoid writing this question :)
(features added since 2.0.x, which
should not be backported)
^ ^ ^
| | | (code refactorings done
| | | in master/trunk)
\ | / (*) (*) (*)
-------------------------------------------------------> master/trunk
| |
| |
| |
\ release-2.0.x \ critical-feature
(should be backported)
Questions:
What would be the best way to perform the feature backporting from the
VCS
perspective?Should this be done as a simple
merge
of the correspondingcritical-feature
branch with conflict-resolving conflicts?Or should this be done as the
cherry-pick
of the commit, which merges thecritical-feature
intomaster/trunk
when it's done? Or maybe even as a set ofcherry-picks
for each commit in thecritical-feature
branch?Could you advise something for the conflict resolution procedure? What should one do if the current difference between
release-2.0.x
andmaster/trunk
is so huge, that "naive" backporting leads to a huge amount of conflicts due to code refactoring and missing features orAPI
, which were added after therelease-2.0.x
?Does
Git
orSubversion
have something specific to offer for this routine except standard merging or cherry-picking approach? I guess that rebasing won't be helpful in case when the amount of conflicts is vast, but, obviously, I might be wrong.