출처: https://nvie.com/files/Git-branching-model.pdf , 작성자: Vincent Driessen
Git Flow
Git Flow 는 2010년 Vincent Driessen 이 작성한 블로그 글을 통해 유명해지기 시작한 Git Branching Model 의 하나로, 현재는 거의 정석과도 같이 자리잡은 방법론입니다. 위의 이미지가 Git Flow 를 소개하는 가장 대표적인 이미지라고 할 수 있죠.
특정한 기술이 아닌, 하나의 방법론이기 때문에 작성자 또한 개발 환경에 맞추어 사용하기를 권하고 있습니다. 그말인즉슨 Git Flow 가 모든 경우에 있어서 완벽한 답안이 되지는 않는다는 것이죠.
그럼에도 Git Flow 는 많은 개발자들이 사용하는 방법론으로 자리잡게 되었습니다. 브랜치가 많아진다는 단점에도 불구하고, 제품 런칭 이후에도 관리하기가 용이하고, 프로젝트 전반에서 발생하는 다양한 워크플로우의 구현이 가능하다는 등 (참고자료) 확실한 장점으로 많은 사랑을 받게 된 것이죠.
Git Flow 의 특징
Git Flow 는 크게는 2 종류로 나눌 수 있는 5 개의 branch 를 사용합니다. Main 브랜치라고 할 수 있는 master 와 develop 브랜치, Supporting 브랜치 라고 할 수 있는 feature, release, hotfix 브랜치 가 있습니다.
master branch : 바로 배포되어 사용 가능한 (production-ready) 상태를 유지하는 브랜치입니다.
develop branch : 가장 최근의 변경사항들을 반영하는 개발 단계에서 사용하는 메인 브랜치입니다.
feature branch : 기능 개발을 위해 develop 브랜치에서 갈라져나온 브랜치로, 기능 구현이 완료되면 다시 develop 브랜치로 병합됩니다.
release branch : 배포를 위해 최종적인 검증 단계를 거치는 브랜치로, develop 또는 master 브랜치로 병합됩니다.
hotfix branch : 배포 중인 master branch 에서 빠르게 수정해야 하는 버그가 발생했을 경우, 개발 단계에 있는 develop branch 대신 바로 master branch 에서 분기해 수정사항을 반영하는 브랜치입니다. master 또는 develop 브랜치로 병합됩니다.
적용
First Project 를 진행하기 위해서 코드스테이츠에서 안내하는 Git Flow 는 위에서 release 와 hotfix 가 빠진 버전입니다. 아무래도 2 주라는 짧은 시간 동안 진행되는 프로젝트인 만큼 굳이 과하게 브랜치를 유지할 이유는 없기 때문이겠죠.
그럼에도 저희 팀은 한 팀원의 제안을 통해 release 브랜치를 적용하는 것을 고려하게 되었습니다. 매일매일 개발한 코드들을 병합해 배포 가능한 상태로 만들어가며 결과물을 확인하기 위해서입니다. dev 브랜치를 활용할 수도 있지만 여러가지를 고려해야 하는 상황 끝에 release 브랜치의 사용을 고민하는 중인데 과연 어떻게 결론이 날지는 내일이 되어봐야 알 수 있을 것 같습니다.
참고할만한 자료
https://techblog.woowahan.com/2553/ ➡️ 우아한 형제들 기술블로그
https://www.youtube.com/watch?v=EzcF6RX8RrQ ➡️ 생활코딩님의 유튜브 영상
