Question

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 upcoming release-2.1.x).

• Now, at some point another feature (namely, critical-feature) was developed and merged back to master/trunk. We realize that this feature is so important, that we have to backport it to release-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 corresponding critical-feature branch with conflict-resolving conflicts?

• Or should this be done as the cherry-pick of the commit, which merges the critical-feature into master/trunk when it’s done? Or maybe even as a set of cherry-picks for each commit in the critical-feature branch?

• Could you advise something for the conflict resolution procedure? What should one do if the current difference between release-2.0.x and master/trunk is so huge, that "naive" backporting leads to a huge amount of conflicts due to code refactoring and missing features or API, which were added after the release-2.0.x?

• Does Git or Subversion 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.

Answer 1

The all idea of backporting features looks broken for me. Only critical and non-destructive changes should be backported. For features and improvements you have to create new branch and start stabilization period.

Check out release process used in Apache Subversion project itself:
https://subversion.apache.org/docs/community-guide/releasing.html#release-stabilization