Git-Flow는 병합기반의 솔루션이며 여러 개발자가 하나의 저장소에서 협업할 때 매우 효율적인 전략이다.(기능개발 단계, 준비 및 테스트 단계, 배포 단계 등 각 단계를 효율적인 방법으로 나눈 브랜치 전략)
우리팀은 다수의 인원이 하나의 저장소에서 함께 개발하지는 않지만 Github Action(github workflow 전략)을 적용함에 있어 Git-Flow 전략대로 가져가는게 좋다 판단(단계별로 workflow 작성)하여 Git-Flow 도입을 결정하였다. 겸사겸사 탄탄한 협업 능력도 기르고~
Git-Flow Core 기능 + 규칙
Git-Flow 전략은 5개의 큰 줄기의 branch가 존재한다.
- master
- release에서 테스트 완료되어 제품으로 출시될 브랜치(이 브랜치로 merge시 배포 자동화)
- 현재 스토어에 배포된 버전임. 문제 발생 시 → hotfix 브랜치로 checkout
- release
- 출시 준비중인 브랜치 (version tag가 달려있음)
- 여기서 앱 테스트
- 앱 테스트 중 오류 수정 & 내부 QA 통과 시 master로 merge
- develop
- 기능개발의 시작점이자 개발종료 후 merge 될 곳
- 기능개발 된 이후 release로 version 달아서 머지
- feature
- 기능개발 브랜치
- hotfix
- 출시된 버전(master branch)에서 발생한 버그를 수정하는 브랜치
- 수정 완료시 master 및 develper branch에 merge
💻 Git-Flow 설치
- git flow 전략대로 branch 틀을 만들어주고 git flow 명령어 사용가능하게 해줌
# git flow 설치
brew install git-flow-avh
# 해당 repository root에서
git flow init🙋🏻 새 기능 개발 & 개발완료
- 새 기능의 개발은
develop에서 시작 즉, develop 브랜치에서 checkout 해야함. - 새 기능 branch의 이름은
feature/{Jira 티켓넘버}(우리 팀에서는 branch 명을{branch}/{Jira 티켓번호}로 설정하기로 했다.) - 아래는 새 기능 branch 만들기 명령어 및 기능완료 명령어
git flow feature start {Jira 티켓넘버}
# develop에 merge & 해당 branch 삭제 & develop브랜치로 자동 전환
git flow feature finish {Jira 티켓넘버}
# 그러나 우린 GUI툴인 Fork를 사용한다!😃 새 버전 출시 준비 & 테스트
develop내에서 기능개발 완료 시 →release/vX.X.X로 merge- develop에 merge되면 release로 merge하는 자동화(Github Action 사용할 예정)
release브랜치로 push 되면 테스트 버전 앱 생성(server는 stage라 부르기로 하자)- iOS(테스트 플라이트로 업로드), Android(APK추출 및 Slack으로 뿜뿜)
- Firebase App Distribution는 나중에 도입하기로 하자
- 테스트 하면서 오류는
release에 수정 및 push - 테스트 완료 시
master에 merge
🥳 새 버전 출시
master에 merge 시 배포 자동화 로직 수행- 앱 배포!
😭 출시 버전에서 오류
- 출시 된 버전에서 예상치 못한 오류 발생시
master에서hotfix/{Jira 티켓번호}로 checkout - hotfix 수정완료시
develop및master에 merge시키기 (자동화?)
🧑🏻💻 전체적인 흐름
Life Designer