핫픽스를 처리하는 동안 여러 활성 릴리스에 대한 적절한 Git 워크 플로우

우리 제품에 가장 적합한 Git 워크 플로를 선택하려고합니다. 매개 변수는 다음과 같습니다.

• 우리는 일년에 몇 번의 주요 릴리스를 수행합니다.
• 동시에 여러 버전의 제품이 활성화되어 있습니다 (일부 사람들은 v10.1, 일부는 v11.2 등).
• 동시에 여러 릴리스에서 작업 할 수 있어야합니다 (v12.1에서 작업 할 수 있지만 릴리스가 끝날 때 v12.2에서 동시에 작업하기 시작 함)
• 중요한 버그가 발견되면 핫픽스 릴리스를 할 수 있어야합니다

지금까지 내가 생각하는 방식은 다음과 같습니다.

• 단일 원격 저장소가 사용됩니다
• 마스터에서 분기 12.1 생성
• 12.1을 기준으로 피쳐 브랜치를 생성하고 커밋 한 후 다시 12.1로 병합
• 향후 릴리스에서 작업을 시작해야하는 경우 12.1을 기반으로 새 분기 12.2를 작성하십시오.
• 그런 다음 12.1의 기능에 대해 작업 할 때 12.1에서 분기를 작성하고 변경 사항을 커미트 한 후 12.1과 12.2로 병합하십시오.
• 12.2의 기능에 대해 작업하는 경우 12.2에서 분기를 작성하고 변경 사항을 커미트 한 후 12.2로만 병합하십시오.
• 릴리스 12.1이 완료되면이를 마스터 및 태그 마스터 분기에 병합하고 12.1을 사용하십시오.
• 핫픽스가 필요한 경우 가장 오래된 릴리스 분기에서 핫픽스 분기를 만들고 변경 사항을 커밋 한 다음 해당 릴리스 및 영향을받을 수있는 향후 릴리스의 모든 릴리스 분기로 다시 병합합니다. 최신 안정 릴리스 브랜치가 영향을받은 경우이를 마스터로 병합하십시오.

몇 가지 우려 사항이 있습니다.

• 오래된 분기에서 새 분기로 핫픽스를 병합하는 것이 특히 프로세스가 겹치는 경우 매끄럽게 진행 될지 확신 할 수 없습니다. 충돌이있는 것처럼 보이는 경우 각 지점에서 수동으로 핫픽스를 작성하는 것이 더 똑똑합니다.
• 내가 본 워크 플로우 모델은 릴리스 브랜치가 마스터에 병합되고 태그가 지정되고 제거되면 릴리스 브랜치를 많이 유지하지 않는 것 같습니다. 내 문제는 마스터에 태그가있는 모든 릴리스가있는 경우 릴리스 상태를 관리하는 방법을 잘 모른다는 것입니다. 브랜치에서 핫픽스를 사용하는 것이 더 쉬운 것처럼 보이고 항상 다시 돌아갈 수있는 릴리스가 있습니다. 최신 핫픽스가 있습니다 (릴리스의 핫픽스에 태그를 지정할 수도 있음). 마스터로 돌아가서 핫픽스가 적용된 릴리스 사본을 가지고 해당 태그를 업데이트하는 방법이 있는지 확실하지 않습니다.

내가 명시한 요구 사항에 따라 간과했을 수도 있고 더 나은 방법으로 의견을 보내주십시오.

모든 주요 릴리스 (12.0.0)에서 분기 된 후 각 업데이트 (12.1.0) 및 핫픽스 (12.2.1)에 대한 사소한 업데이트가있을 수 있습니다. 옳은?

릴리스가 종료 된 후 GitFlow에서 릴리스 분기를 활성 상태로 유지할 수없는 특별한 이유는 없습니다. 여러 분기 분기 간의 변경을 오랫동안 조정하는 것이 어떤 모델에서도 어렵다는 사실 외에는 없습니다. GitFlow가 다음 라이브 버전을 개발하면서 단일 라이브 릴리스를 유지하는 제품에 대해 더 모델링 된 것으로 가정합니다.

나는 GitFlow를 고수하고 몇 가지 수정을 할 것이다.

마스터 브랜치를 건너 뜁니다. 나는 지금까지 그것을 실제로 사용하지 않았으며 작업 방식에 따라 선형성을 잃을 것입니다. 다음 주요 릴리스의 개발을 계속 개발하십시오. 마스터를 유지하기로 결정한 경우 릴리스 태그를 마스터에 두지 말고 배송 할 바이너리를 생성 한 릴리스 브랜치의 마지막 커밋에 배치하십시오.

릴리스 브랜치를 다시 병합하여 개발 한 후에는 버리지 마십시오. 대신 다음 마이너 릴리스 및 가능한 핫픽스를 위해 주변에 보관하십시오. 릴리스 지원을 중단 한 경우 삭제하는 것이 좋습니다. 주 구성 요소 인 release / 12 다음에 릴리스 브랜치의 이름을 지정한 다음 release / 12.1, release / 12.2에서 하위 릴리스 브랜치를 작성할 수 있습니다. 이 수준의 병렬 처리에 대해 너무 걱정할 필요는 없었지만 아마도 시도했을 것입니다. 이 경우 각 주요 릴리스 브랜치를 자체 하위 GitFlow 환경으로 생각할 수 있습니다.

향후 몇 가지 주요 릴리스의 기능에 대해 동시에 병렬 작업을 수행해야하는 경우 개발에서 다음 버전 (13)과 추가 "develop-N"분기의 이후 버전 (14, 15)을 유지해야합니다. . 그것은 일반적으로 유지하기가 매우 어려워 보이지만 가능할 것입니다.

귀하의 주요 문제에 대한 가능한 해결책 ( «우리는 동시에 여러 릴리스에서 작업 할 수 있어야합니다 [...]» )git worktree add <path> [<branch>]

git 저장소는 여러 작업 트리를 지원할 수 있으므로 한 번에 둘 이상의 브랜치를 체크 아웃 할 수 있습니다.
를 사용 git worktree add하면 새로운 작업 트리가 저장소와 연결됩니다.

이 새로운 작업 트리는 " git init"또는 " git clone"로 준비된 "주 작업 트리"와 달리 "링크 된 작업 트리 " 라고 합니다.
저장소에는 하나의 기본 작업 트리 (빈 저장소가 아닌 경우)와 0 개 이상의 연결된 작업 트리가 있습니다.

에 대한 자세한 소개는 이 SO 답변 을 참조하십시오 git worktree.

gitflow에 익숙하다고 언급했습니다. 나는 당신의 시나리오를 위해 그것을 채택하는 것이 좋습니다. 이전 버전을 지원하려면 개발 지점에서 지점을 작성해야합니다. 이러한 이전 버전에는 자체 릴리스 / 마스터 브랜치 및 핫픽스 브랜치도 있어야합니다. 지원 지점을 최신 지원 지점과 개발 지점으로 정기적으로 병합해야합니다.

메이저 버전의 개발이 다양 해짐에 따라 계속 더 어려워 질 것입니다. 이에 대한은 총알이 없습니다. 때로는 수동으로 변경하는 것이 더 쉬울 수 있습니다. 이전 버전을 유지하는 데 드는 비용이 증가하고 어느 시점에서는 더 이상 가치가 없습니다.

모든 것은 이전 버전에서 어떤 종류의 변경을 수행 하느냐에 달려 있습니다. 버그 수정 만하면 비교적 쉽게 병합 할 수 있습니다. 새로운 기능을 추가하려고하면 어려울 것입니다.