01 -a Git branch strategy 명명규칙 및 전략

• 기능은 feature에서 만들어 develop에 모으고, 배포 준비가 끝나면 main으로 올린다.
• 운영 버그는 main에서 hotfix를 따서 고치고, main과 develop 양쪽에 합친다.
• 커밋 메시지는 feat, fix, hotfix, docs 접두어로 시작한다.

브랜치 생성 및 운영

작업 브랜치는 개인별 branch를 사용한다.

기능이 끝나면 develop으로 합치고, 배포 준비가 되면 main으로 올린다. 급한 운영 버그는 main에서 hotfix를 따서 고친 뒤 develop에도 다시 반영한다.

화살은 항상 위로만 간다. main에서 직접 작업하지 않고, develop을 건너뛰고 main에 바로 합치는 것도 hotfix 하나뿐이다.

커밋 규칙

신규 기능 : feat 버그 수정 : fix 운영 긴급 수정 : hotfix 문서 : docs

접두어 뒤에는 무엇을 바꿨는지 한 줄로 쓴다. 로그만 훑어도 어느 커밋이 기능이고 어느 게 수정인지 바로 보여서, 릴리스 노트 쓸 때 훨씬 편했다.

1. Main Branch

Release(배포)출시 할 수 있는 브랜치

최종 배포 이력을 남기는 최상위 브랜치다. 여기에는 배포 가능한 상태만 올린다.

2. Dev Branch

다음 출시 버전을 개발하는 브랜치

main에서 따 와서, 기능 브랜치들을 모으는 데 쓴다. 개발은 이 브랜치를 기준으로 하고, 기능이 다 들어가고 버그도 잡혀서 배포해도 되겠다 싶을 때 develop을 main에 병합(merge)한다.

3. 작업branch(Feature branch)

기능을 개발하는 브랜치 (Local)

feature 브랜치는 새로운 기능 개발 및 버그 수정이 필요할 때마다 ‘develop’에서 따낸다. 작업 중인 내용을 굳이 공유할 필요가 없어서 보통은 내 로컬 저장소에서 관리한다.

개발이 완료되면 ‘develop’ 브랜치로 병합(merge)하여 다른 사람들과 공유한다.

‘develop’ 브랜치에서 새로운 기능에 대한 feature 브랜치를 분기한다.

새로운 기능에 대한 작업 수행한다.

작업이 끝나면 Local에서 개발한 Feature 브랜치를 develop에 병합한다.

합친 develop을 중앙 원격(Remote) 저장소에 올린다.(push) 리뷰를 받을 땐 feature 브랜치를 먼저 push하고 PR로 합친다.

더 이상 필요 없는 feature 브랜치는 지운다.

배포 직전 정리나 핫픽스가 필요하면 release / hotfix 브랜치를 잠깐 쓴다. release는 develop에서 따서 버전 고정·최종 점검용으로 쓰고, hotfix는 이미 나간 main의 급한 결함만 고친 뒤 main과 develop 양쪽에 다시 합친다. 오른쪽 그림은 그 병합 흐름을 그린 것이다.

브랜치 이름은 종류/내용 모양으로 맞춘다. release와 hotfix는 버전 번호를 그대로 붙여서, 태그와 브랜치 이름이 어긋나지 않게 한다.