기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# Gitflow 전략의 브랜치
<a name="branches-in-a-gitflow-strategy"></a>

Gitflow 분기 전략에는 일반적으로 다음과 같은 분기가 있습니다.



![\[Gitflow 분기 전략의 분기 및 환경입니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/choosing-git-branch-approach/images/gitflow-branching-strategy.png)


## 기능 브랜치
<a name="feature-branch"></a>

`Feature` 브랜치는 기능을 개발하는 단기 브랜치입니다. `feature` 브랜치는 브`develop`랜치에서 분기하여 생성됩니다. 개발자는 `feature`브랜치에서 코드를 반복, 커밋 및 테스트합니다. 기능이 완료되면 개발자는 해당 기능을 승격합니다. 특성 브랜치에서 전달되는 경로는 두 개뿐입니다.
+ `sandbox` 브랜치에 병합
+ `develop` 브랜치에 병합 요청 생성


|  |  | 
| --- |--- |
| 명명 규칙: | `feature/<story number>_<developer initials>_<descriptor>` | 
| 명명 규칙 예제: | `feature/123456_MS_Implement_Feature_A` | 

## 샌드박스 브랜치
<a name="sandbox-branch"></a>

`sandbox` 브랜치는 Gitflow의 비표준 단기 브랜치입니다. 그러나 CI/CD 파이프라인 개발에 유용합니다. `sandbox` 브랜치는 주로 다음과 같은 목적으로 사용됩니다.
+ 수동 배포 대신 CI/CD 파이프라인을 사용하여 샌드박스 환경에 대한 전체 배포를 수행합니다.
+ 개발 또는 테스트와 같은 하위 환경에서 전체 테스트를 위한 병합 요청을 제출하기 전에 파이프라인을 개발하고 테스트합니다.

`Sandbox` 브랜치는 본질적으로 일시적이며 수명이 길지 않습니다. 특정 테스트가 완료된 후 삭제해야 합니다.


|  |  | 
| --- |--- |
| 명명 규칙: | `sandbox/<story number>_<developer initials>_<descriptor>` | 
| 명명 규칙 예제: | `sandbox/123456_MS_Test_Pipeline_Deploy` | 

## 브랜치 개발
<a name="develop-branch"></a>

`develop` 브랜치는 기능이 통합, 구축, 검증 및 개발 환경에 배포되는 수명이 긴 브랜치입니다. 모든 `feature`브랜치는 브`develop`랜치에 병합됩니다. `develop` 브랜치로의 병합은 성공적인 빌드와 2개의 개발자 승인이 필요한 병합 요청을 통해 완료됩니다. 삭제를 방지하려면 브랜치에서 `develop`브랜치 보호를 활성화합니다.


|  |  | 
| --- |--- |
| 명명 규칙: | `develop` | 

## 릴리스 브랜치
<a name="release-branch"></a>

Gitflow에서 브`release`랜치는 단기 브랜치입니다. 이러한 브랜치는 build-once, deploy-many 방법론을 수용하여 여러 환경에 배포할 수 있으므로 특별합니다. `Release`브랜치는 테스트, 스테이징 또는 프로덕션 환경을 대상으로 할 수 있습니다. 개발 팀이 기능을 더 높은 환경으로 승격하기로 결정한 후 새 `release`브랜치를 생성하고 이전 릴리스의 버전 번호 증가를 사용합니다. 각 환경의 게이트에서 배포를 진행하려면 수동 승인이 필요합니다. `Release`브랜치는 병합 요청을 변경해야 합니다.

`release` 브랜치를 프로덕션에 배포한 후에는 `develop` 및 `main`브랜치에 다시 병합하여 버그 수정 또는 핫픽스가 향후 개발 작업에 다시 병합되도록 해야 합니다.


|  |  | 
| --- |--- |
| 명명 규칙: | `release/v{major}.{minor}` | 
| 명명 규칙 예제: | `release/v1.0` | 

## 기본 브랜치
<a name="main-branch"></a>

`main` 브랜치는 프로덕션에서 실행 중인 코드를 항상 나타내는 수명이 긴 브랜치입니다. 코드는 릴리스 파이프라인에서 성공적으로 배포된 후 릴리스 `main`브랜치에서 브랜치로 자동으로 병합됩니다. 삭제를 방지하려면 브랜치에서 `main`브랜치 보호를 활성화합니다.


|  |  | 
| --- |--- |
| 명명 규칙: | `main` | 

## bugfix 브랜치
<a name="bugfix-branch"></a>

브`bugfix`랜치는 프로덕션에 릴리스되지 않은 릴리스 브랜치의 문제를 해결하는 데 사용되는 단기 브랜치입니다. `bugfix` 브랜치는 `release`브랜치의 수정 사항을 테스트, 스테이징 또는 프로덕션 환경으로 승격하는 데만 사용해야 합니다. `bugfix` 브랜치는 항상 브`release`랜치에서 분기됩니다.

버그 수정을 테스트한 후 병합 요청을 통해 `release`브랜치로 승격할 수 있습니다. 그런 다음 표준 릴리스 프로세스에 따라 `release`브랜치를 앞으로 푸시할 수 있습니다.


|  |  | 
| --- |--- |
| 명명 규칙: | `bugfix/<ticket>_<developer initials>_<descriptor>` | 
| 명명 규칙 예제: | `bugfix/123456_MS_Fix_Problem_A` | 

## 핫픽스 브랜치
<a name="hotfix-branch"></a>

`hotfix` 브랜치는 프로덕션 문제를 해결하는 데 사용되는 단기 브랜치입니다. 프로덕션 환경에 도달하기 위해 신속하게 처리해야 하는 수정 사항을 승격하는 데만 사용됩니다. `hotfix` 브랜치는 항상에서 분기됩니다`main`.

핫픽스를 테스트한 후 병합 요청을 통해에서 생성된 `release`브랜치로 핫픽스를 프로덕션으로 승격할 수 있습니다`main`. 그런 다음 테스트를 위해 표준 릴리스 프로세스에 따라 `release`브랜치를 앞으로 푸시할 수 있습니다.


|  |  | 
| --- |--- |
| 명명 규칙: | `hotfix/<ticket>_<developer initials>_<descriptor>` | 
| 명명 규칙 예제: | `hotfix/123456_MS_Fix_Problem_A` |