Git-Flow 간략 설명

메인 브랜치

항상 유지되는 브랜치

• master: 제품으로 출시되는 브랜치
• develop: 다음 출시 버전을 개발하는 브랜치

보조 브랜치

일정 기간 동안만 유지되는 브랜치

• feature: 신규 기능을 개발하는 브랜치
• release: 새로운 버전 출시를 준비하는 브랜치
• bugfix: 새로운 버전 출시를 준비중에 발생하는 변경을 하는 브랜치
• hotfix: 출시된 버전에서 발생한 버그를 수정하는 브랜치

Git 기본정책

• 모든 작업은 Jira 티켓을 생성하여 진행
• Jira티켓:PR=1:N 관계
• PR 머지 시 squash
• 메인 브랜치 변경은 PR을 통해서만 가능
• PR은 1명 이상의 리뷰어가 approve 해야 머지 가능
• 머지는 저자 (author)가 직접함

Case 별 Git-Flow 전략

Auto Merge를 활용하기 위해서는 각 브랜치의 prefix 규칙을 지켜야한다.

각 브랜치별 prefix 규칙을 아래와 같이 정한다.

Branch	Prefix
feature	feature/
release	release/
bugfix	bugfix/
hotfix	hotfix/

CASE 1) 신규 기능 개발

Branch From	Branch Name	Branch To (PR)	Auto Merge
develop	feature/{jira}/{name}	develop	-

신규 기능 개발 건은 다음 릴리즈를 위해 준비하는 것임으로 develope 브랜치에서 따와서 작업하고 develope 브랜치로 머지한다.

CASE 2) 검증 및 출시

Branch From	Branch Name	Branch To (PR)	Auto Merge
develop	release/{jira}/{phase}	master	PR로 master로 머지 시 develope 자동 머지

검증은 다음 릴리즈를 준비하는 것으로 develope 브랜치에서 따온다. Jenkins 배포 시 형상 별로 릴리즈 브랜치를 나누어 개발 편의를 반영했다. 검증이 완료되면 master 브랜치로 머지되어 출시한다. 이때 검증과정에서 변경된 코드를 develope에도 반영하기 위해 auto merge를 설정할 수 있다.

CASE 3) 검증 중 수정

Branch From	Branch Name	Branch To (PR)	Auto Merge
release/{jira}/{phase}	bugfix/{jira}/{phase}/{name}	release/{jira}/{phase}	-

검증 중 나온 이슈에 대한 수정 사항을 릴리즈 브랜치에서 브랜치를 따와 작업한다. 그리고 작업이 완료되면 다시 릴리즈 브랜치로 머지한다.

CASE 4) 운영 긴급 수정

Branch From	Branch Name	Branch To (PR)	Auto Merge
master	hotfix/{jira}/{name}	master	PR로 master로 머지 시 develope 자동 머지

운영 중 발생한 긴급 수정 건은 master 브랜치에서 hotfix 브랜치를 따와서 작업하며 작업이 완료되면 master 브랜치로 머지하여 운영 배포한다. 이 변경 분을 develop 브랜치에도 반영이 되어야함으로 Auto Merge 기능을 활용한다.