Adam Dymitruk ("기능 별 분기")에 설명 된 워크 플로우의 이전 릴리스에서 버그 수정

Question

나는 Adam Dymitruk's git workflow에서 읽었으며 모든 것이 적합합니다.

내가 토론에서 찾을 수없는 한 가지는 이전 릴리스에서 버그를 수정하는 것입니다. 7.0, 7.1, 7.2, 7.3, 7.4, 7.4.1, 7.4.1, 7.4.2, 7.8, 8.2 및 가장 최신의 태그가있는 'master'브랜치 그림 8

특정 클라이언트의 프로덕션 버전은 7.2이며, 버그가 발견되어 고쳐 져야합니다.

8.3.1에서 수정하고 7.2에서 8.3.1로 클라이언트를 이동하는 것은 클라이언트에게 허용되지 않습니다.

그래서 권장되는 워크 플로우가 있습니까?

7.2 태그에서 master 브랜치의 포크를 생성하고이 브랜치를 release-7.2.x로 호출 할 수 있습니다. 그런 다음 master 브랜치를 처리하는 것처럼 'release-7.2.x'를 처리하십시오. 버그 (72bug)를 수정하고, 버그 등을 고치고, 최종적으로 feature 브랜치를 'release-7.2.x'로 병합하고, 빌드하고, 7.2.1 태그를 만들고, 그것을 프로덕션에 넣습니다. 'release-7.2.x'는 마스터와 마찬가지로 영원히 지속될 것이므로 release-7.2.x에서 7.2.x에 대한 더 이상의 수정이 가능합니다.

물론 현재 작업에 대해 7.2에서 수정 사항을 잃고 싶지 않으므로 현재 마스터 기준선 (8.3)에서 기능 분기를 만들고이 기능 분기로 버그 분기 (72bug)를 병합 할 수 있습니다 . 이 기능 브랜치는 현재 출시주기/스프린트의 다른 기능처럼 처리됩니다. 따라서주기가 끝나면 최신 기준선 (8.4)에 버그 수정이 포함됩니다.

아담의 워크 플로우를 사용하는 다른 사람들이이 상황을 어떻게 해결 했습니까?

Answer 1

클라이언트를 현재 버전으로 마이그레이션 할 수없는 경우 7.2 태그에서 새 분기를 시작하는 것이 실제로는 없습니다.

72bug 브랜치에서 버그를 수정하고이를 release-7.2.x 브랜치와 현재 기능 브랜치에 병합하는 대신, 현재 기능 브랜치에서 버그를 수정 한 다음 git cherry-pick을 사용하여 수정 사항을 release-7.2.x 브랜치에 백 포트하십시오. 이렇게하면 역사를 깨끗하게 유지할 수 있으므로 현재 개발이 한 클라이언트의 요구로 인해 갑자기 이전 버전에 의존하는 것처럼 보이지 않습니다.