728x90
Git Branch 전략
Git-Flow 브랜치를 나누는 방법에 대한 분류 중 하나
gitFlow특징 -> 브랜치를 5종류로 나눔
- master : 제품으로 출시될 수 있는 브랜치
- develop : 다음 출시 버전을 개발하는 브랜치
- feature : 기능을 개발하는 브랜치
- release : 이번 출시 버전을 준비하는 브랜치
- hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치
- main, develop은 필수 브랜치이지만 나머지 브랜치는 유지 보수를 목적으로 하는 선택적인 브랜치
- branch를 merge할 때 항상 -no-ff 옵션을 붙여 branch에 대한 기록이 사라지는 것을 방지하는 것을 원칙으로 한다.
Git-Flow 과정
참고: 우아한형제들 기술블로그 (우린 Git-flow를 사용하고 있어요)
- master 브랜치에서 develop 브랜치를 분기
- 개발자들은 develop 브랜치에 자유롭게 커밋
- 기능 구현이 있는 경우 develop 브랜치에서 feature-* 브랜치를 분기
- 배포를 준비하기 위해 develop 브랜치에서 release-* 브랜치를 분기
- 테스트를 진행하면서 발생하는 버그 수정은 release-* 브랜치에 직접 반영
- 테스트가 완료되면 release 브랜치를 master와 develop에 merge
위 그림을 일반적인 개발 흐름으로 살펴보겠습니다.
처음에는 master와 develop 브랜치가 존재합니다. 물론 develop 브랜치는 master에서부터 시작된 브랜치입니다. develop 브랜치에서는 상시로 버그를 수정한 커밋들이 추가됩니다. 새로운 기능 추가 작업이 있는 경우 develop 브랜치에서 feature 브랜치를 생성합니다. feature 브랜치는 언제나 develop 브랜치에서부터 시작하게 됩니다. 기능 추가 작업이 완료되었다면 feature 브랜치는 develop 브랜치로 merge 됩니다. develop에 이번 버전에 포함되는 모든 기능이 merge 되었다면 QA를 하기 위해 develop 브랜치에서부터 release 브랜치를 생성합니다. QA를 진행하면서 발생한 버그들은 release 브랜치에 수정됩니다. QA를 무사히 통과했다면 release 브랜치를 master와 develop 브랜치로 merge 합니다. 마지막으로 출시된 master 브랜치에서 버전 태그를 추가합니다. -https://techblog.woowahan.com/2553/