-
Notifications
You must be signed in to change notification settings - Fork 4
Git Branch 전략
최우창 edited this page Jul 12, 2023
·
22 revisions
브랜치 | 역할 | 규칙 |
---|---|---|
main |
배포 브랜치 | 단일 브랜치. 배포되어 있다. 삭제하지 않는다. |
hotfix |
버그, 에러 수정 브랜치 | main 브랜치에서 만든다. main브랜치와 dev브랜치에 머지하면 삭제한다. |
dev |
개발 브랜치 | 신규 기능 브랜치의 시작점이자 합류점, 기능 개발의 총합이다. 삭제하지 않는다. |
feat |
신규 기능 브랜치 | feat/{이슈번호} 명칭을 준수한다. dev에 merge된 feat 브랜치는 삭제한다. |
상황 | 브랜치 |
---|---|
운영 | main |
베타 | dev |
핫픽스 대응 | hotfix |
롤백 대응 | hotfix |
dev와 독립적으로 발생한 문제를 main에서 처리하기 위해 hotfix 브랜치를 이용합니다.
- main에서 hotfix 브랜치를 생성해서 bug fix, version bumping 등의 작업을 진행합니다. ex) hotfix/1.1
- hotfix 브랜치에서 작업이 끝나면 hotfix 브랜치를 최신 dev와 main에 각각 merge합니다.
- dev: hotfix 브랜치에서 bug fix 등 수정사항들이 dev에도 반영되어야 하기 때문
- main: 버그가 수정된 새 version을 release 하기 위해
main 브랜치를 롤백해야 할 정도 심각한 경우 기존 hotfix 브랜치와 다르게 처리합니다.
- 메인 브랜치는 이전 버전으로 전환하고,
- 기존 핫픽스 전략과 달리 dev에서 main으로 보낸 tag를 찾아 hotfix 브랜치를 생성한다.
- 때문에 dev에서 main으로 머지할 때 태그를 꼭 남겨야 한다.
- 이후 문제 해결 후 main/dev에 머지한다.
타입 | 설명 |
---|---|
feat |
(#이슈번호) 새로운 기능 추가 |
fix |
(#이슈번호) 버그 수정 |
docs |
(#이슈번호) 문서 수정 |
style |
(#이슈번호) 공백, 세미콜론 등 스타일 수정 |
refactor |
(#이슈번호) 코드 리팩토링 |
perf |
(#이슈번호) 성능 개선 |
test |
(#이슈번호) 테스트 추가 |
chore |
(#이슈번호) 빌드 과정 또는 보조 기능(문서 생성 기능 등) 수정 |
design |
(#이슈번호) 기능 수정 없이 스타일(CSS)만 수정 |
우아한테크코스 5기 VoTogether 팀