Git Branch 종류
1. Master branch
제품으로 출시 될 수 있는 브랜치
배포(Release)이력을 관리하기 위해 사용. 즉, 배포 가능한 상태만을 관리한다.
2. Develop branch
다음 출시 버전을 개발하는 브랜치
3. Feature branch
기능을 개발하는 브랜치
feature 브랜치는 새로운 기능 개발 및 버그 수정이 필요할 때마다 develop 브랜치로부터 분기한다.
feautre 브랜치에서의 작업은 기본적으로 공유할 수 없기 때문에, 자신의 로컬 저장소에 관리한다.
개발이 완료되면 ‘develop’ 브랜치로 병합(merge)하여 다른 사람들과 공유한다.
- ‘develop’ 브랜치에서 분리
- 새로운 기능에 대한 작업 수행
- 작업이 완료 되면 ‘develop’ 브랜치로 병합(merge)
- 더 이상 필요하지 않은 feature 브랜치는 삭제
- 새로운 기능에 대한 ‘feature’ 브랜치를 중앙 원격 저장소에 올린다.(push)
feature 브랜치 이름 정하기
4. Release branch
이번 출시 버전을 준비하는 브랜치
배포를 위한 전용 브랜치를 사용함으로써 한 팀이 해당 배포를 준비하는 동안 다른 팀은 다음 배포를 위한 기능 개발을 계속할 수 있다. 즉, 딱딱 끊어지는 개발 단계를 정의하기에 아주 좋다.
- ‘develop’ 브랜치를 만드는 순간부터 배포 사이클이 시작
- release 브랜치에서는 배포를 위한 최종적인 버그 수정, 문서 추가 등 릴리스와 직접적으로 관련된 작업을 수행한다.
- 직접적으로 관련된 작업들을 제외하고는 release 브랜치에 새로운 기능을 추가로 병합(merge)하지 않는다.
다음 번 배포(release)를 위한 개발 작업은 'develop' 브랜치에서 계속 진행해 나간다.
‘release’ 브랜치에서 배포 가능한 상태가 되면 (배포 준비가 완료되면)
배포 가능한 상태: 새로운 기능을 포함한 상태로 모든 기능이 정상적으로 동작하는 상태
‘master’ 브랜치에 병합한다. 이때, 병합한 커밋에 release 버전 태그를 부여
배포를 준비하는 동안 release 브랜치가 변경되었을 수 있으므로 배포 완료 후 ‘develop’ 브랜치에서도 병합한다.
5. Hotfix branch
출시 버그에서 발생한 버그를 수정하는 브랜치
배포한 버전에 긴급하게 수정을 해야 할 필요가 있을 경우, master브랜치에서 분기하는 브랜치이다.
- 배포한 버전에 긴급하게 수정을 해야 할 필요가 있을 경우 ‘master’ 브랜치에서 hotfix 브랜치를 분기한다. (‘hotfix’ 브랜치만 master에서 바로 딸 수 있다.)
- 문제가 되는 부분만을 빠르게 수정
- 다시 ‘master’ 브랜치에 병합(merge)하여 이를 안정적으로 다시 배포한다.
- 새로운 버전 이름으로 태그를 매긴다.
- hotfix 브랜치에서의 변경 사항은 ‘develop’ 브랜치에서도 병합(merge)한다.
브랜치 이름 정하기
[hotfix-*] 형식을 추천 ex)hotfix-1.2.1
6. 참고
- https://gmlwjd9405.github.io/2018/05/11/types-of-git-branch.html
- https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
- https://nvie.com/posts/a-successful-git-branching-model/