브랜치 전략
- 제품으로 출시되는 브랜치 입니다.
- 배포(Release) 이력을 관리하기 위해 사용 합니다.
- 다음 출시 버전을 개발하는 브랜치 입니다.
- ‘Develop’ 브랜치를 기반으로 개발을 진행 합니다.
- 신규 기능 개발을 위한 브랜치 입니다.
- ‘Develop’ 브랜치에서 분기하여 작업 후 작업이 완료되면 Develop 브랜치에 병합(merge) 후 Feature 브랜치는 삭제 합니다.
- 1.0.0 , 1.0.1 등 버젼을 올리는 기준은 1주차별로(혹은 2주차) 진행을 할까 합니다.
- 브랜치 네이밍은 [feature/버전명_이슈번호] 형식을 사용합니다. EX) feature/1.0.0_123
(그림에서 Master 브랜치가 Main이라고 생각하면 될 것 같아요)
예를 들어 설명하는게 편할 것 같아서 예시를 들어보도록 하겠습니다.
- 유진님이 깃헙 이슈에 소셜 로그인 기능을 올렸습니다
- 해당 이슈 넘버는 3번이라고 가정하겠습니다.
- 현재 깃헙에는 Main 브랜치, Develop 브랜치, Feature/1.0.0 브랜치가 존재합니다.
- 해당 브랜치를 따오는 순서는 다음과 같습니다. Main 브랜치 -> Develop 브랜치 -> feature/1.0.0
- 유진님은 이슈 넘버 3번이므로 feature/1.0.0 브랜치에서 따와 feature/1.0.0_3 브랜치를 로컬에 생성합니다.
- 로컬에서 코드 작성 후 feature/1.0.0 브랜치로 MR을 요청합니다.
- 팀원들은 코드 리뷰 후 approve를 하고, MR을 날린 사람이 직접 merge를 실행합니다.
- Merge가 완료되면 issue를 close 합니다.
- 유진님이 ‘Develop’ 브랜치에서 ‘feature/1.0.0_123’ 브랜치를 분기하여 작업 합니다. (로그인 작업)
- 범준님이 ‘Develop’ 브랜치에서 ‘feature/1.0.0_124’ 브랜치를 분기하여 작업하고 있습니다. (회원가입 작업)
- 유진님이 개발중인 ‘feature/1.0.0_123’ 브랜치의 작업이 완료 되면 develop에 병합(merge) 합니다.
- 범준님은 ‘develop’ 브랜치에 신규 기능이 추가되었으니 작업중인 ‘feature/1.0.0_124’ 브랜치에 병합(pull)하고 conflicts들을 처리 합니다.
- 범준님의 회원가입 기능이 완료되면 작업한 ‘feature/1.0.0_124’ 브랜치를 ‘develop’ 브랜치에 병합(merge) 합니다.
- 다음버전으로 배포를 위한 기능이 구현되어 ‘develop’ 브랜치에서 분기한 ‘release-1.1’ 브랜치를 생성 합니다.
- ‘release’ 브랜치에서 배포를 위한 최종적인 버그 수정, 문서 추가 등 릴리스와 직접적으로 관련된 작업을 수행 합니다.
- ‘master’ 브랜치에 release 브랜치를 병합(merge)하고 새로운 버전을 배포 합니다.
4번 작업을 수행하는 이유는 회원가입 기능이 완료되어 ‘develop’ 에 머지하는 시점에 conflict 들을 처리하는것보다 다른 작업을 진행중인 ‘feature/1.0.0_124’에 먼저 병합하여 conflict를 처리하는것이 보다 안전하다고 판단했기 때문입니다.