Jaki byłby preferowany sposób osiągnięcia następującego przepływu pracy z jednym lub drugimGit lubSubversion (Mam większe zainteresowanieGit wersja, ale porównanie z pewnością będzie przydatne):

Powiedzmy, że niedawno wydaliśmy główne wydanie produktu, a konkretny oddział polisihin nazywa sięrelease-2.0.x.

Rozwój był kontynuowany ikilka oddziałów funkcji zostały połączone wmaster/trunk (później staną się częścią nadchodzącegorelease-2.1.x).

Teraz w pewnym momencie inna funkcja (mianowicie,critical-feature) został opracowany i połączony z powrotemmaster/trunk. Zdajemy sobie sprawę, że ta funkcja jest tak ważna, że ​​musimy ją przenieść dorelease-2.0.x.

Oto mała pseudograficzna ilustracja opisanego przypadku. Zauważ, że wszystko na górze wprowadza różnice między drzewamirelease-2.0.x i prądmaster/trunk iprowadzi do łączenia problemów (inaczej mógłbym po prostu połączyćcritical-feature i unikaj pisania tego pytania :)

    (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)

Pytania:

Jaki byłby najlepszy sposób wykonania funkcji przenoszenia zVCS perspektywiczny?

Powinno to być prostemerge odpowiadającegocritical-feature oddział z konfliktami rozwiązującymi konflikty?

Lub powinno to być zrobione jakocherry-pick zatwierdzenia, które łączycritical-feature wmaster/trunk Kiedy się zakończy? A może nawet jako zestawcherry-picks za każde zatwierdzenie wcritical-feature Oddział?

Czy możesz coś doradzić w procedurze rozwiązywania konfliktów? Co należy zrobić, jeśli aktualna różnica międzyrelease-2.0.x imaster/trunk jest tak ogromny, że „naiwne” backportowanie prowadzi do ogromnej liczby konfliktów z powodu refaktoryzacji kodu i brakujących funkcji lubAPI, które zostały dodane porelease-2.0.x?

RobiGit lubSubversion mieć coś specjalnego do zaoferowania w tej procedurze, z wyjątkiem standardowego łączenia lub podejścia wiśniowego? zgaduję, żerebasing nie będzie pomocne w przypadku, gdy ilość konfliktów jest ogromna, ale oczywiście mogę się mylić.