하나 이상의 주요 버전이 유지 관리되는 프로젝트에서 어떻게 git-flow를 효과적으로 사용할 수 있습니까?


18

여러 프로젝트를 git flow 워크 플로우 로 마이그레이션했으며 좋아합니다. 그러나 한 번에 하나 이상의 주요 버전이 유지 관리되는 프로젝트로 작업 할 때 원활하게 흐름을 유지하는 모범 사례를 찾지 못했습니다.

특히, 나는 "무료 버전"과 "유료 버전"또는 다른 병렬 모델을 유지하고 있지 않으며, 버전 1이 릴리스되고 마이너 버전 (1.1, 1.2 등)이 지원되는 프로젝트에 대해 이야기하고 있습니다. .) 버전 3이 릴리스 될 때까지, 2 및 3이 유지 될 때까지, 4가 릴리스 될 때까지 ... 아이디어를 얻습니다.

gitflow 워크 플로에서 지원되는 두 가지 이상의 버전의 프로젝트를 한 번에 어떻게 유지 했습니까?


atm에 대한 예제는 없지만 다른 주요 버전에 대해 별도의 저장소를 사용하고 패치를 백 포트 패치로 사용했습니다.
ProdigySim

@ProdigySim : 데이터 포인트에 대해 감사하지만 추적 및 관리에 어느 정도의 오버 헤드가 추가됩니까?
HedgeMage

@ProdigySim 나는 그 프로젝트가 git의 분기 및 병합 기능을 가진 도구를 사용하지 않았다고 생각합니다.
Rein Henrichs

@Rein 그들은 Mercurial을 사용합니다. 병렬 주요 버전의 소프트웨어를 추적하는 측면에서 분기가 매우 깨끗하다고 ​​생각하지 않습니다.
ProdigySim

그런 다음 내 의심이 맞았습니다. 그리고 도구가 올바르게 지원한다면 아주 깨끗합니다. git과 Linux 커널 모두이 방법으로 수행합니다.
Rein Henrichs

답변:


10

man gitworkflows'git flow'워크 플로우의 대부자는 일반적인 git 워크 플로우 지침을 설명합니다. 의 사용 pu, next, mastermaint지점; 그리고 어떻게 maint관리됩니다. 여러 유지 보수 지점을 가지고 있다면, 당신은 그 이름을, 예를 들어, 수 maint/1.x, maint/2.x등등.

핵심은 git 명령을 사용하는 방법이 아니라 합리적인 프로세스를 만드는 방법입니다. 중요한 사항 (백 포트 용이성)을 결정하고 이러한 제약 조건을 충족하는 워크 플로를 작성 (및 문서화)하십시오.


그러나 이것이 질문에 대답합니까? 즉, git-flow는 질문에 설명 된대로 유연한 릴리스 모델을 지원합니까? 아니면 기본 git 명령으로 되돌 립니까? ( "gitworkflows"는 기본 git workflow 사용법, pre-git-flow를 설명합니다.) Git-flow는 git merge / branch 프로세스를 단순화하기 위해 (명확하게) 만들어 졌으므로 팀 (git-fu prowess의 정도가 다양 함)은 코딩 및 시간이 많이 걸리는 "mis-mergerment"실수를 피하십시오. v2.5. {1,2,3, ...}와 동시에 v1.2. {1,2,3, ..}을 유지하고 개발할 수있는 git-flow가 있습니까? 아마도 장기 릴리스 지점이 있습니까? 아니면 master1, master2, ...?
마이클

0

기본적으로, 당신은 중복 것 master, release그리고 develop당신은 유지하고 모든 주요 버전에 지점을. 그들이 서로 상호 작용하는 방식은 동일하게 유지됩니다. 들어 feature가지, 단지 지점에 있는지 확인 에서 다시 병합하려는 가장 오래된 지점 방지 원치 않는 의존성 당기는. 그런 다음 feature지점을 다시 병합 할 때 적절한 각 최신 주요 버전 지점으로 추가 병합을 수행하면됩니다.


1
마스터 버전이 모든 출시 된 버전 을 포함하지는 않습니까?
HedgeMage

@HedgeMage는 좀 더 선형적인 릴리스주기이지만 병렬 메이저 버전에는 비실용적입니다.
Karl Bielefeldt

핫픽스를 사용하거나 내가 알지 못하는 트릭이없는 한, 이것은 가장 실용적인 해결책처럼 보입니다. 나는 git-flow를 소개하는 방법을 찾고 있었고 여전히 (불행한 전제 조건으로) 기존 릴리스 모델을 유지할 수 있습니다. 이전 버전은 핫픽스뿐만 아니라 이전 릴리스를 유지 관리 / 개발해야합니다. 따라서 v5.1.x는 v6.1.x가 출시 된 후 몇 년이 지난 후 새로운 기능이 추가되거나 버그가 수정되는 등의 문제가 발생할 수 있습니다. 주어진 시간에 약 2-3 개의 주요 버전이 지원 및 개발됩니다. 그러나 버그가 존재하는 각 버전에 버그 수정을 적용해야합니다.
마이클
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.