# Branch 전략

## Branch 전략

* 개발자들이 협업하고 소프트웨어를 개발하는데 사용되는 브랜치 전략 및 워크플로우

### Git Flow

<figure><img src="https://1912740209-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F3GVYdZvmqQyBVq29ebqk%2Fuploads%2F0LMAVs1nDMXNmXu8wFYe%2Fgit_flow.png?alt=media&#x26;token=cbde3943-9334-4798-bbc2-2af23717f1ed" alt=""><figcaption></figcaption></figure>

#### 주요 브랜치

* `main` (제품 출시 버전)
* `develop` (다음 출시를 위한 통합 브랜치)

#### 보조 브랜치

* `feature` (새 기능 개발)
* `release` (출시를 준비하는 브랜치)
* `hotfix` (긴급 버그 수정)

#### 단점

* 브랜치가 너무 많다!&#x20;
  * 이를 개선하기 위해 간소화된  **Github Flow**가 나옴

### GitHub Flow&#x20;

Github에서 깃을 잘 관리하기 위해 만든 flow

<figure><img src="https://1912740209-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F3GVYdZvmqQyBVq29ebqk%2Fuploads%2F7QGoSmPgNHcqx9VN68d3%2Fgithub-flow.png?alt=media&#x26;token=d7a2fed4-4e6a-485f-bc2e-e7501d9ca972" alt=""><figcaption></figcaption></figure>

#### 주요 브랜치

* main (항상 배포 가능한 상태를 유지)

#### 브랜치 생성

* 기능 추가 및 버그 수정을 위해 새로운 브랜치를 만들고, 작업이 끝나면 main으로 통합

#### 배포

* 릴리즈 관리는 태깅을 통해 수행

#### 장점

* 단순하고 직관적
* 지속적인 배포에 용이
* 소규모 팀의 애자일 및 지속적 개발에 적합
* 작은 변경사항을 빠르게 배포
* Github Action 자동화 용이 (적은 브랜치, 단순해서)&#x20;
* 쉬운 롤백
* 빠른 사용자 피드백

#### 단점

* 대규모 프로젝트의 복잡성 다루기
  * 다양한 팀, 의존성 등을 다루기엔 너무 단순함
* 독립적인 기능을 구현하기 어려움
* 코드 충돌 가능성 높음
* 잦은 배포는 롤백이 복잡해짐

#### Flow 예시

* 브랜치 생성
  * 새로운 기능 및 버그 수정은 main 브랜치에서 새로운 브랜치 생성
* 코드 작업
* Pull Request

### GitLab Flow

<figure><img src="https://1912740209-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F3GVYdZvmqQyBVq29ebqk%2Fuploads%2FlxlLUelvYcZCEppFIvGE%2Fgitlab.png?alt=media&#x26;token=513ed780-2c14-4079-a5f3-bf9354222bc3" alt=""><figcaption></figcaption></figure>

#### 주요 브랜치

* main (계속해서 배포 가능한 상태를 유지)

#### 브랜치 생성

* 새로운 기능과 버그 수정과 같은 작업은 새로운 브랜치에서 시작하여 개발
* main 브랜치로 병합하기 전  Merge Request 생성

#### 배포

* &#x20;코드가 main 으로 머지되면 자동으로 배포 파이프라인 실행

### Feature Branch Workflow

### Git-Flow Extension

### Trunk-Based Development

### Release Flow

### 추가적으로 고려할 점

* QA를 어느 브랜치에서 할 것인가?
* 병렬적인 개발을 위한 브랜치 전략은?