1. 웹 개발에서 Git Flow를 쓰는 이유와 장점1-1. 스프린트/버전 단위로 타 부서와 협업할 수 있습니다.1-1-1. 굳이 왜? QA 시의 효율성 때문입니다.2. 예시 시나리오2-1. 개발 시작부터 첫 스프린트가 끝나기까지2-2. [비공식] 차후 출시를 위한 작업이 생긴 경우3. 출처
1. 웹 개발에서 Git Flow를 쓰는 이유와 장점
1-1. 스프린트/버전 단위로 타 부서와 협업할 수 있습니다.
핵심: 릴리즈 별로 격리된 브랜치를 사용하면 버전 단위로 작업이 가능합니다.
Git Flow에는
release
브랜치가 있고, 릴리즈 시에는 해당 브랜치에서 작업할 수 있습니다.1-1-1. 굳이 왜? QA 시의 효율성 때문입니다.
테스트할 때 (스프린트에 속한) 최소한의 변경만 있다면, 문제 원인 파악 난도를 최대한 낮추고 테스트 범위도 최소화할 수 있습니다.
미래 버전(스프린트)의 코드를 격리시킬 수 있다면
- 개발팀은 문제의 원인을 최대한으로 좁힐수 있고,
- QA팀은 의도치 않은 side effect가 발생했을 때 추가로 해야 하는 QA를 방지할 수 있습니다.
스프린트를 기준으로 작업을 보면 3가지 분류가 존재합니다.
- 스프린트에서 계획된 작업
- 스프린트에서 계획되었다가 빠진 작업
- 스프린트에서 계획되지 않은 작업
이 중 [스프린트에서 계획된 작업]과 [나머지 2가지 유형의 작업]을 격리시켜야 합니다. Git Flow는 이를
release
브랜치를 두는 것으로 구현합니다.2. 예시 시나리오
[git flow 흐름도]
- git flow는 기본적으로 브랜치의 역할과 관계에 대한 방법론입니다.
2-1. 개발 시작부터 첫 스프린트가 끝나기까지
main
만 있는 상태에서 시작합니다.
- 스프린트를 계획합니다. 버전
0.0.1
develop
브랜치를main
으로부터 생성합니다.
develop
에서 스프린트 상의 이슈를 모두 처리합니다.- 각 feature에 대해
feature
브랜치를 만들어 작업한 후 병합합니다.
- 모든 이슈가 처리된 경우,
develop
에서release/0.0.1
브랜치를 생성합니다. - QA 팀을 통해 버그 목록을 수집하고,
bugfix
브랜치를 만들어 작업합니다.
release/0.0.1
브랜치에서 출시를 위한 완전한 준비가 되면main
에 병합해서 배포합니다.- 이 때 배포는 주로 자동화합니다.
- 해당 commit에 대해 버전
0.0.1
로 태그를 만들어둡니다.
release/0.0.1
을develop
에도 병합해bugfix
변경 사항들을 반영합니다.
- 갑자기 실 서버에서 버그가 발생한다. 이 경우
main
에서hotfix
브랜치를 생성해 작업합니다.
hotfix
브랜치의 작업이 완료된 경우,main
,develop
둘 모두에 병합합니다.
2-2. [비공식] 차후 출시를 위한 작업이 생긴 경우
기본적인 Git Flow는 이 상황을 전제로 설명하지 않아, 비공식적인 내용입니다.
- 버전
0.0.1
스프린트 중인 상태에서, 그 이후 스프린트를 수행할 여력이 생긴 상황입니다.
develop
에서 격리된 임의의 브랜치(e.g.future/0.0.2
)를 생성합니다.
future
를 임시의develop
으로 활용하여 개발합니다.
- 현재
release/0.0.1
이 작업이 완료되고,develop
에 병합되면 그 때future/0.0.2
도develop
에 병합합니다.
- 이후
0.0.2
버전의 스프린트 작업을develop
에서 모두 수행하고,release/0.0.2
브랜치를 생성해 QA를 거치면서 배포를 준비하면 됩니다.