[iOS 개발] 브랜치 전략 세우기

프로젝트를 진행하면서 브랜치 전략에 대해서 생각을 해볼 기회가 생겼다

 

기존에 깃과 브랜치에 대한 개념이 매우 부족했었는데 이번 기회에 해당 부분의 지식들도 많이 습득할 수 있었던 좋은 기회였던 것 같다.

 

프로젝트에 적용한 브랜치 전략은 다음과 같다.

 

 

 

 

 

브랜치 전략

 

Master branch

- 제품으로 출시되는 브랜치 입니다.
- 배포(Release) 이력을 관리하기 위해 사용 합니다.

 

Develop branch

- 다음 출시 버전을 개발하는 브랜치 입니다.
- ‘Develop’ 브랜치를 기반으로 개발을 진행 합니다.

 

Feature branch

- 신규 기능 개발을 위한 브랜치 입니다.
- ‘Develop’ 브랜치에서 분기하여 작업 후 작업이 완료되면 Develop 브랜치에 병합(merge) 후 Feature 브랜치는 삭제 합니다.
- 1.0.0 , 1.0.1 등 버젼을 올리는 기준은 1주차별로(혹은 2주차) 진행을 할까 합니다.
- 브랜치 네이밍은 [feature/버전명_이슈번호] 형식을 사용합니다. EX) feature/1.0.0_123

(그림에서 Master 브랜치가 Main이라고 생각하면 될 것 같아요)

---

예를 들어 설명하는게 편할 것 같아서 예시를 들어보도록 하겠습니다.

예시1: 유진님이 소셜 로그인 기능을 개발하는 경우

1. 유진님이 깃헙 이슈에 소셜 로그인 기능을 올렸습니다
2. 해당 이슈 넘버는 3번이라고 가정하겠습니다.
3. 현재 깃헙에는 Main 브랜치, Develop 브랜치, Feature/1.0.0 브랜치가 존재합니다.
4. 해당 브랜치를 따오는 순서는 다음과 같습니다.
Main 브랜치 -> Develop 브랜치 -> feature/1.0.0
5. 유진님은 이슈 넘버 3번이므로 feature/1.0.0 브랜치에서 따와 feature/1.0.0_3 브랜치를 로컬에 생성합니다.
6. 로컬에서 코드 작성 후 feature/1.0.0 브랜치로 MR을 요청합니다.
7. 팀원들은 코드 리뷰 후 approve를 하고, MR을 날린 사람이 직접 merge를 실행합니다.
8. Merge가 완료되면 issue를 close 합니다.

예시2: 범준과 유진이 동시에 같은 브랜치를 따와 작업하는 경우

1. 유진님이 ‘Develop’ 브랜치에서 ‘feature/1.0.0_123’ 브랜치를 분기하여 작업 합니다. (로그인 작업)
2. 범준님이 ‘Develop’ 브랜치에서 ‘feature/1.0.0_124’ 브랜치를 분기하여 작업하고 있습니다. (회원가입 작업)
3. 유진님이 개발중인 ‘feature/1.0.0_123’ 브랜치의 작업이 완료 되면 develop에 병합(merge) 합니다.
4. 범준님은 ‘develop’ 브랜치에 신규 기능이 추가되었으니 작업중인 ‘feature/1.0.0_124’ 브랜치에 병합(pull)하고 conflicts들을 처리 합니다.
5. 범준님의 회원가입 기능이 완료되면 작업한 ‘feature/1.0.0_124’ 브랜치를 ‘develop’ 브랜치에 병합(merge) 합니다.
6. 다음버전으로 배포를 위한 기능이 구현되어 ‘develop’ 브랜치에서 분기한 ‘release-1.1’ 브랜치를 생성 합니다.
7. ‘release’ 브랜치에서 배포를 위한 최종적인 버그 수정, 문서 추가 등 릴리스와 직접적으로 관련된 작업을 수행 합니다.
8. ‘master’ 브랜치에 release 브랜치를 병합(merge)하고 새로운 버전을 배포 합니다.

4번 작업을 수행하는 이유는 회원가입 기능이 완료되어 ‘develop’ 에 머지하는 시점에 conflict 들을 처리하는것보다 다른 작업을 진행중인 ‘feature/1.0.0_124’에 먼저 병합하여 conflict를 처리하는것이 보다 안전하다고 판단했기 때문입니다.

 

 

 

참고링크:

https://velog.io/@ssol_916/Git-Branch-%EC%A0%84%EB%9E%B5%EC%9D%98-%EB%8C%80%ED%91%9C%EA%B2%A9-Git-Flow-%EC%A0%84%EB%9E%B5