브랜치 전략
Git 브랜치를 구성하고 머지하는 방식을 브랜치 전략이라고 합니다. 그러나 팀에 복잡한 요구 사항(테스트 및 규정 준수 요구 사항 등)이 있는 경우 다른 브랜치 전략을 고려할 수 있습니다. 다음 섹션에서는 일반적으로 사용되는 전략을 설명합니다.
Git 브랜치를 구성하고 머지하는 방식을 브랜치 전략이라고 합니다. 많은 팀에서 가장 단순한 접근 방식이 합리적이고 효과적입니다:
- 기능 브랜치에서 변경합니다.
- 기능 브랜치를
main에 직접 머지합니다.
그러나 팀에 복잡한 요구 사항(테스트 및 규정 준수 요구 사항 등)이 있는 경우 다른 브랜치 전략을 고려할 수 있습니다.
다음 섹션에서는 일반적으로 사용되는 전략을 설명합니다. 모든 직원이 Git(또는 버전 관리) 전문가를 갖추고 있는 것은 아닙니다. 팀이 Git 기술의 한계에서 작업하는 경우 이 정보가 도움이 될 수 있습니다.
GitLab을 여러 개의 다양한 도구를 대체하는 데 사용할 때 Git 브랜치 전략에 대한 결정이 중요합니다. 신중한 계획을 통해 다음 사이에 명확한 연결을 설정할 수 있습니다:
- 받은 초기 버그 보고서.
- 팀이 해당 버그를 수정하기 위해 만드는 커밋.
- 해당 수정 사항을 다른 버전이나 고객에게 백포팅하는 프로세스.
- 사용자에게 수정 사항을 제공하는 배포.
신중한 선택은 GitLab의 단일 데이터 저장소를 최대한 활용하는 데 도움이 됩니다.
더 복잡한 Git 브랜치 전략이 필요한가요?#
현재 Git 브랜치 전략을 능가한 경우:
- 지속적 배포를 사용합니다.
- 상당한 자동화 테스트가 있습니다.
- 다른 고객에게 영향을 미치지 않고 특정 고객의 중요한 버그를 수정해야 합니다.
- 제품의 여러 이전 버전을 유지 관리합니다.
- 제품에 단일 프로덕션 브랜치가 없습니다. 여러 운영 체제 또는 플랫폼을 지원하기 때문입니다.
- 제품에 각 버전마다 다른 배포 또는 인증 요구 사항이 있습니다.
제품에 필요한 것보다 복잡한 전략을 구현하지 마세요.
프로젝트를 여러 저장소로 분할하는 경우#
복잡한 브랜치 구조를 가진 하나의 Git 저장소를 유지할지, 아니면 프로젝트를 여러 저장소에 분산할지 결정해야 합니다. 단일한 정답은 없습니다. 지원할 인력과 전문 지식에 따라 다릅니다.
GitLab은 저장소가 단일 제품을 위한 것이라고 가정하는 자동화를 제공하지만, 해당 제품에는 여러 버전이 포함될 수 있습니다. 여러 저장소가 필요한지 또는 단일 복잡 저장소가 필요한지를 결정하려면 다음 질문을 하세요:
- 같은 제품인가요?
- 모든 요소가 동일한 빌드 프로세스를 사용하나요?
- 기본 코드가 비슷하거나 동일한가요?
복잡한 단일 저장소 또는 더 작은 저장소 세트 중 어느 것을 선택하든 유지 관리에 엔지니어링 시간을 써야 합니다. 어떤 유형의 엔지니어링 작업을 수행할 준비가 되어 있는지 파악하세요:
- 단일 저장소에서 여러 제품의 코드를 유지 관리하는 경우 나중에 GitLab의 모든 기능을 사용하기 위한 사용자 정의 작업을 계획합니다.
- 여러 저장소에 걸쳐 작업을 머지하는 것은 동일한 저장소의 브랜치에서 머지하는 것보다 더 복잡합니다. 사용자 정의 릴리스 프로세스를 구축하고 저장소 전체에 코드 흐름을 관리하기 위한 엔지니어링 시간을 계획합니다.
조직에서 대형 모노레포 또는 메가레포를 사용하는 경우 GitLab의 Professional Services 팀이 필요에 맞는 사용자 정의 브랜치 솔루션을 구축하는 데 도움을 줄 수 있습니다.
주요 브랜치 전략 유형#
브랜치 및 코드 관리 전략은 제품의 요구 사항에 따라 다릅니다. 어떤 기존 전략도 모든 것을 커버할 수 없지만, 주요 범주는 다음과 같습니다:
웹 서비스#
이 전략은 표준 Git 관행을 따릅니다. main 브랜치는 프로덕션 브랜치로, 단일 웹 서비스에 적합합니다: 하나의 표준 프로덕션 버전이 있고 이전 버전에 대한 지원이 없습니다.
이 구성에서는 git-flow가 적합합니다. 표준화되어 있고 유지 관리할 필요가 없습니다.
이 예시에서 feature-1은 main에서 직접 분기됩니다. 완료되면 feature-1은 다시 main으로 직접 머지됩니다. 이 머지 커밋은 사각형으로 강조 표시됩니다. feature-2와 같이 수명이 긴 브랜치는 개발의 일부로 주기적으로 main의 최신 업데이트를 머지할 수 있습니다.
완료되면 feature-2가 main에 머지되고 릴리스 1.1이 만들어집니다:
소스 코드 보기
%%{init: { "gitGraph": { "mainBranchOrder" : 1 }, "fontFamily": "GitLab Sans" }}%%
gitGraph
accTitle: Branching strategy for web services
accDescr: Feature work happens on separate branches that merge directly into the main branch with release tags.
commit tag: "1.0" id: "release v1.0"
branch "feature-1"
commit id: "start feature-1"
checkout main
commit id: "start feature-2"
branch "feature-2" order: 3
checkout feature-1
commit id: "refine feature-1"
checkout main
merge feature-1 type: HIGHLIGHT id: "merge feature-1 into main"
checkout feature-2
commit id: "build feature 2"
merge main type: HIGHLIGHT id: "merge main into feature-2"
commit
checkout main
merge feature-2 tag: "1.1" type: HIGHLIGHT id: "release v1.1"</code></pre></details></div>
수명이 긴 릴리스 브랜치#
이 브랜치 전략은 제품에 오랫동안 main과 분리된 상태를 유지해야 하는 브랜치가 있는 경우 적합합니다. 몇 가지 예시:
- 동일한 소프트웨어 패키지의 여러 프로덕션 버전. 예: 현재 버전과 레거시 버전. 현재 버전은 기능 업데이트와 핫픽스를 받고, 이전 버전은 핫픽스와 보안 릴리스만 받습니다.
- 현재 프로덕션 버전과 수명이 긴 베타 버전. 주요 소프트웨어 의존성(소프트웨어 개발 키트 또는 SDK 등)이 호환성을 깨는 변경 사항을 도입하는 경우 이 접근 방식이 필요할 수 있습니다. 현재 프로덕션 버전은 기능 업데이트와 핫픽스를 받습니다. 베타 버전은 팀이 예정된 SDK 변경 사항에 대한 지원을 구축하면서 이러한 기능 업데이트와 핫픽스를 받습니다.
수명이 긴 브랜치를 잠그려는 경우 핫픽스 프로세스를 정의하고 적용하는 것이 중요합니다.
정의되지 않고 적용되지 않으면 모든 변경 사항이 핫픽스가 됩니다.
이 예시에서 2.0 브랜치는 1.0 릴리스를 위한 main의 커밋에서 만들어집니다.
기능은 2.0 브랜치에서 분기되고 2.0으로 다시 머지됩니다. 동시에 모든 핫픽스 브랜치는 main의 가장 최근 릴리스(1.0)를 기반으로 하며 릴리스 1.1로 main에 다시 머지됩니다. 2.0 브랜치는 릴리스 1.1의 변경 사항을 가져와서 2.0 개발의 일부로 통합합니다. 다른 기능(feature-2)을 추가한 후 2.0 브랜치가 프로덕션 준비가 됩니다. main에 머지되고 릴리스 2.0이 만들어집니다:
Mermaid 다이어그램 (31줄)소스 코드 보기
%%{init: { "gitGraph": { "mainBranchOrder" : 2 }, "fontFamily": "GitLab Sans" }}%%
gitGraph
accTitle: Branching strategy for long-lived releases
accDescr: Hotfixes merge into the main branch while features are developed on a separate long-lived release branch.
commit tag: "1.0"
branch hotfix order: 1
checkout main
branch "2.0" order: 3
commit
checkout hotfix
commit id: "security bug"
commit id: "performance bug"
checkout "2.0"
branch feature-1 order: 4
commit id: "create feature 1"
checkout main
commit id: " "
checkout 2.0
merge feature-1 id:"merge feature-1" tag: "2.0 RC 1"
checkout main
merge hotfix tag: "1.1" type: HIGHLIGHT
checkout 2.0
merge main tag: "2.0 RC 2" type: HIGHLIGHT
branch feature-2 order: 5
commit id: "create feature 2"
commit id: "refine feature 2"
checkout 2.0
merge feature-2 id: "merge feature-2" tag: "2.0 RC 3"
checkout main
merge 2.0 tag: "2.0" type: HIGHLIGHT</code></pre></details></div>
SVN 브랜치 전략에서 마이그레이션#
SVN에서 Git으로 마이그레이션하는 레거시 프로젝트는 브랜치 접근 방식을 검토해야 합니다.
Git의 일부 SVN 중심 브랜치 접근 방식은 GitLab을 최대한 활용하는 것을 방해할 수 있습니다. 재검토할 워크플로우:
main에서 수명이 긴 브랜치(예: 1.0)를 만든 다음 사전 승인된 핫픽스가 아닌 변경 사항을 차단하기 위해 1.0 브랜치를 잠급니다.
- Git은 SVN보다 머지 충돌을 더 잘 처리합니다.
- 계약상 의무가 없는 한 수명이 긴 브랜치 만들기를 피하세요. Git이 충돌을 잘 처리하지만 수명이 긴 브랜치는 여러 브랜치에 수정 사항을 머지하는 데 시간을 써야 합니다.
- 제품이 기능 플래그를 지원하지 않기 때문에 브랜치를 사용합니다.
환경별 브랜치#
이 브랜치 전략은 다른 팀이 구축한 여러 상호 의존적인 서비스가 있는 조직에서 일반적입니다. 폭포수 또는 V-모델 개발 프로세스와 함께 자주 사용됩니다.
이 예시에서 v1.1 RC1로 표시된 커밋이 버전 1.1의 릴리스 후보로 식별됩니다.
기능은 계속 main에서 분기되고 다시 main으로 머지되는 반면, 릴리스 후보 커밋은 test 및 UAT 환경에서 테스트됩니다. 이 프로세스는 릴리스 고려 대상인 각 커밋에 대해 반복됩니다:
Mermaid 다이어그램 (21줄)소스 코드 보기
%%{init: { "fontFamily": "GitLab Sans" }}%%
gitGraph
accTitle: Branching strategy for environment isolation
accDescr: Feature work happens on separate branches while release candidates progress through test and UAT branches for validation.
commit id: "start feature"
branch feature-1
checkout main
commit tag: "v1.1 RC1" id: "start testing"
branch test
checkout feature-1
commit id: "develop feature"
commit id: "refine feature"
checkout test
commit id: " " tag: "v1.1 RC1"
branch UAT
checkout UAT
commit tag: "v1.1"
checkout main
merge feature-1 id: "merge feature-1"
commit</code></pre></details></div>
관련 주제#