728x90
Git Flow 전략
언제 브랜치를 파고, 커밋을 할지 정한 git 전략
브랜치 종류
feature > develop > release > hotfix > master
- 메인 브랜치
- master, develop
- 항시 유지되는 브랜치
- 보조 브랜치
- feature, release, hotfix
- 머지되면 사라짐
- Master : 라이브 서버에 제품으로 출시되는 브랜치
- develop: 다음 출시 버전 개발 브랜치
- feature : 추가 기능 (develop에 들어감)
- release : 다음 버전 출시를 준비하는 브랜치
- develop을 release로 옮긴 후, QA 진행하고 master에 합침
- hotfix : master에서 발생한 버그 수정
보조 브랜치
Develop에서 뻗어나오고 다시 합쳐지는 브랜치
release
배포를 위한 최종적인 버그 수정 등의 개발 수행
- 새로운 제품 배포 시 사용
- Develop에서 뻗어나옴
- Develop, Master에서 다시 합쳐짐
- 이름 설정 : release-*
hotfix
- 배포한 버전에서 긴급 수정
- Master에서 뻗어나옴
- Develop, Master에 다시 합쳐짐
- 이름 : hotfix-*
- tag를 통해 관련 정보 기록
- 수정사항을 develop에도 적용하여 conlict 해결
전략 과정
1. 신규 기능 개발
- develop에서 feature 브랜치 생성
- 기능 완성 후 develop 브랜치에 merge 진행
2. 라이브 서버로 배포
- 모든 feature를 develop에 merge 후, QA를 위한 release 생성
- release에서 검증 후, master로 merge
- 수정 시, develop에도 merge함
3. 배포 후 관리
- 라이브 서버(master)에서 버그 빌생 시, hotfix 생성하여 수정
- 수정 시, master와 develop 양쪽에 merge
이를 github에 적용하기 힘드므로 github flow를 사용함
GitHub Flow
특징
- release가 구분되지 안흔 시스템에서 사용
- Github에는 배포가 없음
- hotfix와 작은 기능 구분하지 않음
1. 브랜치 생성
- 어떤 이유로든 새로운 브랜치를 생성
- 단, 이 때, 체계적인 분류 없이 브랜치 하나에 의존하게 되기 때문에 브랜치 이름을 통해 의도를 명확하게 드러내는 것이 매우 중요함
- 새 브랜치는 무조건 master에서 생성
- feature나 develop 존재하지 않음
2. 개발 & 커밋 & 푸시
- 커밋 메시지에 의존하므로 최대한 상세하게 작성
- 원격지 브랜치로 수시로 push
- 항상 원격지에 하고 있는 것을 올려 다른 사람들에게 확인시켜줌
3. PR 생성
- 피드백, 도움 필요시, 머지 준비 완료 시 생성
4. 리뷰 & 토의
- PR이 master에 바로 머지 되기 전, 상세한 리뷰와 토의해야함
5. 테스트
- 토의 후 라이브 서버에 배포
- 배포시 문제가 발생하면, master 브랜치 내용을 다시 배포하여 초기화
6. 최종 Merge
- 라이브 서버 배포 후에도 문제 발견되지 않으면, master에 푸시하고 즉시 배포
- master 브랜치는 최신 브랜치
728x90