기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Gitflow 분기 전략
Gitflow는 여러 브랜치를 사용하여 코드를 개발에서 프로덕션으로 이동하는 분기 모델입니다. Gitflow는 릴리스 주기가 예약되어 있고 기능 모음을 릴리스로 정의해야 하는 팀에 적합합니다. 개발은 승인을 받아 통합에 사용되는 개발 브랜치로 병합되는 개별 기능 브랜치에서 완료됩니다. 이 브랜치의 기능은 프로덕션 준비가 완료된 것으로 간주됩니다. 계획된 모든 기능이 개발 브랜치에 누적되면 상위 환경에 배포하기 위한 릴리스 브랜치가 생성됩니다. 이렇게 분리하면 정의된 일정에 따라 이름이 지정된 환경으로 이동하는 변경 사항을 제어할 수 있습니다. 필요한 경우이 프로세스를 더 빠른 배포 모델로 가속화할 수 있습니다.
Gitflow 분기 전략에 대한 자세한 내용은 다음 리소스를 참조하세요.
+ [다중 계정 DevOps 환경을 위한 Gitflow 분기 전략 구현](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-a-gitflow-branching-strategy-for-multi-account-devops-environments.html)(AWS 권장 가이드)
+ [원본 Gitflow 블로그](https://nvie.com/posts/a-successful-git-branching-model/)(Vincent Driessen 블로그 게시물)
+ [Gitflow 워크플로](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow)(Atlassian)
**Topics**
+ [Gitflow 전략의 시각적 개요](visual-overview-of-the-gitflow-strategy.md)
+ [Gitflow 전략의 브랜치](branches-in-a-gitflow-strategy.md)
+ [Gitflow 전략의 장단점](advantages-and-disadvantages-of-the-gitflow-strategy.md)
# Gitflow 전략의 시각적 개요
다음 다이어그램은 [Punnett 사각형](https://en.wikipedia.org/wiki/Punnett_square)처럼 Gitflow 분기 전략을 이해하는 데 사용할 수 있습니다. 세로 축의 브랜치를 가로 축의 AWS 환경과 정렬하여 각 시나리오에서 수행할 작업을 결정합니다. 원으로 표시된 숫자는 다이어그램에 표시된 작업 순서를 안내합니다. 각 환경에서 발생하는 활동에 대한 자세한 내용은이 설명서의 [DevOps 환경을](understanding-the-devops-environments.md) 참조하세요.
![\[각 브랜치 및 환경의 Gitflow 활동의 Punnett 제곱\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/choosing-git-branch-approach/images/gitflow-diagram.png)
# Gitflow 전략의 브랜치
Gitflow 분기 전략에는 일반적으로 다음과 같은 분기가 있습니다.
![\[Gitflow 분기 전략의 분기 및 환경입니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/choosing-git-branch-approach/images/gitflow-branching-strategy.png)
## 기능 브랜치
`Feature` 브랜치는 기능을 개발하는 단기 브랜치입니다. `feature` 브랜치는 브`develop`랜치에서 분기하여 생성됩니다. 개발자는 `feature`브랜치에서 코드를 반복, 커밋 및 테스트합니다. 기능이 완료되면 개발자는 해당 기능을 승격합니다. 특성 브랜치에서 전달되는 경로는 두 개뿐입니다.
+ `sandbox` 브랜치에 병합
+ `develop` 브랜치에 병합 요청 생성
| | |
| --- |--- |
| 명명 규칙: | `feature/__` |
| 명명 규칙 예제: | `feature/123456_MS_Implement_Feature_A` |
## 샌드박스 브랜치
`sandbox` 브랜치는 Gitflow의 비표준 단기 브랜치입니다. 그러나 CI/CD 파이프라인 개발에 유용합니다. `sandbox` 브랜치는 주로 다음과 같은 목적으로 사용됩니다.
+ 수동 배포 대신 CI/CD 파이프라인을 사용하여 샌드박스 환경에 대한 전체 배포를 수행합니다.
+ 개발 또는 테스트와 같은 하위 환경에서 전체 테스트를 위한 병합 요청을 제출하기 전에 파이프라인을 개발하고 테스트합니다.
`Sandbox` 브랜치는 본질적으로 일시적이며 수명이 길지 않습니다. 특정 테스트가 완료된 후 삭제해야 합니다.
| | |
| --- |--- |
| 명명 규칙: | `sandbox/__` |
| 명명 규칙 예제: | `sandbox/123456_MS_Test_Pipeline_Deploy` |
## 브랜치 개발
`develop` 브랜치는 기능이 통합, 구축, 검증 및 개발 환경에 배포되는 수명이 긴 브랜치입니다. 모든 `feature`브랜치는 브`develop`랜치에 병합됩니다. `develop` 브랜치로의 병합은 성공적인 빌드와 2개의 개발자 승인이 필요한 병합 요청을 통해 완료됩니다. 삭제를 방지하려면 브랜치에서 `develop`브랜치 보호를 활성화합니다.
| | |
| --- |--- |
| 명명 규칙: | `develop` |
## 릴리스 브랜치
Gitflow에서 브`release`랜치는 단기 브랜치입니다. 이러한 브랜치는 build-once, deploy-many 방법론을 수용하여 여러 환경에 배포할 수 있으므로 특별합니다. `Release`브랜치는 테스트, 스테이징 또는 프로덕션 환경을 대상으로 할 수 있습니다. 개발 팀이 기능을 더 높은 환경으로 승격하기로 결정한 후 새 `release`브랜치를 생성하고 이전 릴리스의 버전 번호 증가를 사용합니다. 각 환경의 게이트에서 배포를 진행하려면 수동 승인이 필요합니다. `Release`브랜치는 병합 요청을 변경해야 합니다.
`release` 브랜치를 프로덕션에 배포한 후에는 `develop` 및 `main`브랜치에 다시 병합하여 버그 수정 또는 핫픽스가 향후 개발 작업에 다시 병합되도록 해야 합니다.
| | |
| --- |--- |
| 명명 규칙: | `release/v{major}.{minor}` |
| 명명 규칙 예제: | `release/v1.0` |
## 기본 브랜치
`main` 브랜치는 프로덕션에서 실행 중인 코드를 항상 나타내는 수명이 긴 브랜치입니다. 코드는 릴리스 파이프라인에서 성공적으로 배포된 후 릴리스 `main`브랜치에서 브랜치로 자동으로 병합됩니다. 삭제를 방지하려면 브랜치에서 `main`브랜치 보호를 활성화합니다.
| | |
| --- |--- |
| 명명 규칙: | `main` |
## bugfix 브랜치
브`bugfix`랜치는 프로덕션에 릴리스되지 않은 릴리스 브랜치의 문제를 해결하는 데 사용되는 단기 브랜치입니다. `bugfix` 브랜치는 `release`브랜치의 수정 사항을 테스트, 스테이징 또는 프로덕션 환경으로 승격하는 데만 사용해야 합니다. `bugfix` 브랜치는 항상 브`release`랜치에서 분기됩니다.
버그 수정을 테스트한 후 병합 요청을 통해 `release`브랜치로 승격할 수 있습니다. 그런 다음 표준 릴리스 프로세스에 따라 `release`브랜치를 앞으로 푸시할 수 있습니다.
| | |
| --- |--- |
| 명명 규칙: | `bugfix/__` |
| 명명 규칙 예제: | `bugfix/123456_MS_Fix_Problem_A` |
## 핫픽스 브랜치
`hotfix` 브랜치는 프로덕션 문제를 해결하는 데 사용되는 단기 브랜치입니다. 프로덕션 환경에 도달하기 위해 신속하게 처리해야 하는 수정 사항을 승격하는 데만 사용됩니다. `hotfix` 브랜치는 항상에서 분기됩니다`main`.
핫픽스를 테스트한 후 병합 요청을 통해에서 생성된 `release`브랜치로 핫픽스를 프로덕션으로 승격할 수 있습니다`main`. 그런 다음 테스트를 위해 표준 릴리스 프로세스에 따라 `release`브랜치를 앞으로 푸시할 수 있습니다.
| | |
| --- |--- |
| 명명 규칙: | `hotfix/__` |
| 명명 규칙 예제: | `hotfix/123456_MS_Fix_Problem_A` |
# Gitflow 전략의 장단점
Gitflow 분기 전략은 엄격한 릴리스 및 규정 준수 요구 사항이 있는 더 크고 분산된 팀에 적합합니다. Gitflow는 조직의 예측 가능한 릴리스 주기에 기여하며, 이는 대규모 조직에서 선호되는 경우가 많습니다. Gitflow는 가드레일이 소프트웨어 개발 수명 주기를 올바르게 완료해야 하는 팀에도 적합합니다. 이는 전략에 포함된 검토 및 품질 보증 기회가 여러 개 있기 때문입니다. Gitflow는 여러 버전의 프로덕션 릴리스를 동시에 유지해야 하는 팀에도 적합합니다. GItflow의 몇 가지 단점은 다른 분기 모델보다 더 복잡하며 성공적으로 완료하려면 패턴을 엄격하게 준수해야 한다는 것입니다. Gitflow는 릴리스 브랜치 관리의 엄격한 특성으로 인해 지속적 전달을 위해 노력하는 조직에 적합하지 않습니다. Gitflow 릴리스 브랜치는 적시에 제대로 해결되지 않으면 기술 부채가 누적될 수 있는 수명이 긴 브랜치일 수 있습니다.
## 장점
Gitflow 기반 개발은 개발 프로세스를 개선하고, 협업을 간소화하고, 소프트웨어의 전반적인 품질을 향상시킬 수 있는 몇 가지 이점을 제공합니다. 다음은 몇 가지 주요 이점입니다.
+ **예측 가능한 릴리스 프로세스** - Gitflow는 정기적이고 예측 가능한 릴리스 프로세스를 따릅니다. 정기적인 개발 및 릴리스 주기가 있는 팀에 적합합니다.
+ 공동 **작업 개선** - Gitflow는 `feature` 및 `release`브랜치 사용을 장려합니다. 이 두 브랜치는 팀이 서로에 대한 종속성을 최소화하면서 병렬로 작업하는 데 도움이 됩니다.
+ **여러 환경에 매우 적합** - Gitflow는 수명이 더 긴 `release`브랜치일 수 있는 브랜치를 사용합니다. 이러한 브랜치를 통해 팀은 장기간에 걸쳐 개별 릴리스를 대상으로 지정할 수 있습니다.
+ **프로덕션의 여러 버전** - 팀이 프로덕션의 여러 소프트웨어 버전을 지원하는 경우 Gitflow `release`브랜치는이 요구 사항을 지원합니다.
+ **기본 제공 코드 품질 검토** - Gitflow는 코드를 다른 환경으로 승격하기 전에 코드 검토 및 승인을 사용하도록 요구하고 장려합니다. 이 프로세스는 모든 코드 프로모션에 대해이 단계를 요구하여 개발자 간의 마찰을 제거합니다.
+ **조직 이점** - Gitflow는 조직 수준에서도 이점이 있습니다. Gitflow는 조직이 릴리스 일정을 이해하고 예상하는 데 도움이 되는 표준 릴리스 주기의 사용을 권장합니다. 이제 비즈니스는 새로운 기능을 제공할 수 있는 시기를 이해하므로 전달 날짜가 설정되어 있기 때문에 타임라인에 대한 마찰이 줄어듭니다.
## 단점
Gitflow 기반 개발에는 개발 프로세스와 팀 역학에 영향을 미칠 수 있는 몇 가지 단점이 있습니다. 다음은 몇 가지 주목할 만한 단점입니다.
+ **복잡성** - Gitflow는 새로운 팀이 학습할 수 있는 복잡한 패턴이며 이를 성공적으로 사용하려면 Gitflow 규칙을 준수해야 합니다.
+ **지속적 배포** - Gitflow는 많은 배포가 프로덕션에 신속하게 릴리스되는 모델에 맞지 않습니다. 이는 Gitflow에서 여러 브랜치를 사용하고 브`release`랜치를 관리하는 엄격한 워크플로를 사용해야 하기 때문입니다.
+ **브랜치 관리** - Gitflow는 여러 브랜치를 사용하므로 유지 관리가 어려울 수 있습니다. 브랜치를 서로 올바르게 정렬하려면 다양한 브랜치를 추적하고 릴리스된 코드를 병합하는 것이 어려울 수 있습니다.
+ **기술 부채** - Gitflow 릴리스는 일반적으로 다른 분기 모델보다 느리기 때문에 릴리스에 더 많은 기능이 누적되어 기술 부채가 누적될 수 있습니다.
팀은 Gitflow 기반 개발이 프로젝트에 적합한 접근 방식인지 결정할 때 이러한 단점을 신중하게 고려해야 합니다.