git flow
git branch전략에 대해 알아보자
일반적으로 다음과 같은 flow를 따른다
개발단계 - QA단계 - 운영단계
여기서 사용될 브랜치 전략에 따른 관리를 자동화 시켜주는 툴이 git flow이고, git flow말고도 다른 여러 툴이 존재한다 (Github flow | Gitlab flow | shrunk based flow …)
언제나 main 브랜치를 보존하기 위함
개발단계든, QA, 운영단계 이던지간에 언제나 main을 보존하기 위해 이러한 전략을 사용한다
큰 흐름은 다음과 같다
Main -> (기능추가를 위함) -> develp branch(항상 최신내용을 담음, 영구) -> main
단계별 전략
개발단계
Feature/ * (기능 개발을 하는 동안만 유효) from develop
기능개발 완료 후 -> develop -> delete
이 귀찮은 과정 -> git flow avh (익스텐션)로 자동화 (IntelliJ)
QA단계
Release/ * (QA를 하는 동안에만 유효)
(ex. Release/1.0.0 | release/alpha .. ) from develop
Bugfix/ * (QA를 하는 동안에만 유효) from release
QA완료 후 release 브랜치 삭제
운영단계
Hotfix/* (운영기간 중에만 유효) from main
핫픽스 완료 후 -> develop -> main
유연함
내가 근무하는 곳의 환경은 테스트를 위한 브랜치가 따로 존재한다
( alpha - beta - (real => main) )
따라서 release브랜치를 사용하지 않고, alpha, beta로 사용
(가상release = alpha / beta)
하지만 삭제는 하지 않음(영구)
git flow 기능 (git flow avh)
- Start Feature : feature브랜치 생성 및 이동 from develop
- Publish Feature : 해당 feature브렌치에 push
- Finish Feature : develop에 머지 후 브랜치 삭제 (협업에서 수동 PR로 먼저 검토 권장)
같은 맥락으로 (Start, Publish, Finish) Release, Bugfix, Hotfix를 위한 기능이 존재한다.
release는 main에서 가져오고,
bugfix는 release (혹은 alpha, beta처럼 가상release)에서 가져오며,
hotfix는 main에서 가져오는 맥락
