git branch management strategy
- 여러 개발자가 협업하여 개발하는 환경에서 git 저장소를 효율적으로 사용하기 위한 work-flow
- 브랜치의 생성, 삭제, 병합이 자유로운 유연한git 구조를 활용해 다양한 방식으로 소스를 관리한다.
장점
- 어느 branch가 최신인지 알 수 있다.
- 배포할때 어떤 branch를 기준으로 수정할지, 배포 버전이 무엇인지 알기 쉬움
브랜치 전략의 종류
1. git flow : 5가지 브랜치 종류로 운영
2. github-flow : Master브랜치와 Pull Request (단순한 방법)
git-flow
- 깃크라켄 공식 문서 사진
브랜치의 종류는 항상 유지되는 2개의 메인 브랜치와 역할을 완료하면 사라지는 3개의 보조 브랜치로 구성된다.
메인 브랜치 :
master(main) - 제품 출시 가능
develop - 다음 출시 버전 개발용
보조 브랜치 : merge시 사라진다.
feature - 기능 개발용
release - 현재 출신 버전 준비
hotfix - 출시 버전에서 나온 버그 수정
git-flow 개발 프로세스
- 개발자는 develop 브랜치로부터 본인이 개발할 기능을 위한 feature 브랜치를 생성
- feature브랜치에서 기능이 완성되면 develop에 merge
- 이전 배포버전 기능들이 develop브랜치에 모두 merge되었다면 QA(품질보증)를 위해 release 브랜치를 생선
- realease에서 오류가 생긴다면 release브랜치 내에서 수정한다. QA가 끝나고 나면 해당 버전을 배포하기 위해 maser브랜치로 merge한다. bugfix가 있다면 해당 내용을 반영하기 위해 develop 브랜치에도 merge한다.
- 만약 제품(master)에서 버그가 발생하면 hotfix 브랜치를 생성해 버그를 고친다.
- 버그 픽스가 끝나면 각각 develop과 master에 merge한다.
git-flow 특징
- 주기적으로 배포를 하는 서비스
- 많은 IDE에서 지원된다.
github-flow
제품이 릴리즈되는 최신버전인 master브랜치만 존재한다.
개발 프로세스
- 기능개발, 버그 픽스, 등등..의 이유로 브랜치를 생성한다.
git-flow처럼 체계적인 분류가 없기 때문에 브랜치의 이름은 의도를 아주 잘 드러내야한다. - 개발 도중 커밋 메시지도 상세하게 적어준다.
- 개발 완료 후 Pull Request
- 충분한 리뷰와 토의를 거치고 해당 내용을 실제 서버에 배포한다.
- 이상이 없다면 master에 merge후 push하고 즉시 배포한다.(배포 자동화 권장)
특징
- 브런치 전략이 단순해 git을 처음 접하는 사람에게도 유용
- CI(지속적인 통합), CD(지속적인 배포)가 자연스럽다.
git vs github flow
- 한달 이상 긴 호흡으로 개발하고, 주기적으로 배포하며 QA 및 배포, hot fix를 수행할 수 있는 여력이 있는 팀
vs
- 항상 릴리즈되어야 할 필요가 있는 서비스와 지속적으로 테스트하고 배포하는 팀(CI&CD 자동화)
