"Git 브랜치는 선택이 아닌 필수!"

'Git'은 대표적으로 많이 사용하는 버전관리도구이다. 또 다른 대표 버전관리도구인 'SVN'과의 차이는 브랜치 기능이다.

하지만 첫 회사에서는 신입 개발자들 대부분이었기 때문에 브랜치 사용법을 잘 몰랐고 게다가 프로젝트 기능 구현에 쫓겨 아무도 브랜치를 사용할 생각을 하지 않았다. 그것은 굉장히 큰 실수였다. 브랜치를 사용하지 않으면 일반적으로 'master'(github는 'main') 브랜치 하나만 존재하는데 이렇게 되면 에러가 포함된 코드를 'Commit&Push' 를 하는 경우 'pull'을 받은 동료들 모두 에러를 조치하지 않으면 개발을 할 수 없게 된다. 바쁘면 굉장히 예민해서 서로 얼굴 붉히는 경우가 종종 일어나곤 했다.

이 때문에 'Branch'가 필요하다.

그러나 나는 이직을 하고나서야 브랜치를 사용하게 되었다. 이직 후 맡은 프로젝트에는 브랜치가 버전별로 대략 100여개가 존재했는데 무분별하게 생성하였기 때문인지 아무도 해당 브랜치들의 'history'를 알고 있는 사람이 없었다.

그래서 찾아보게 되었고 깃 브랜치 전략인 'Git Flow'에 대해 학습하게 되었다.

"Git Flow란 무엇일까?"

깃 플로우는 Vincent Driessen이 자신의 블로그에 게시하면서 널리 알려지게 되었다. 현재까지도 인기 있는 브랜치 관리 모델 중 하나이다.

Git Flow의 구성요소는 5가지가 있다.

1) Master : 항상 배포 가능한 상태를 유지하기 위한 브랜치
2) Develop: 다양한 기능 개발과 버그 수정 작업이 지속적으로 진행되는 기본 브랜치
3) Feature: 독립적으로 개발하기 위해 목적 단위로 생성하고 삭제하는 브랜치
4) Release: 실제 배포를 준비하여 Develop 브랜치에서 분기하며, 테스트 및 마무리 작업을 진행하기 위한 브랜치
5) Hotfixes: 실제 배포된 제품에서 긴급한 버그 수정을 위한 브랜치

Git Flow 초기 상태는 master와 develop 브랜치 두 개가 존재한다. develop 브랜치에서 기능별 or 개발자별로 구현 하기위해 feature 브랜치를 생성한다. 구현이 끝나면 finish로 develop에 merge하고 feature 브랜치는 생명주기가 다해 사라지게 된다. 버전별 목표 구현이 끝났다면 release 브랜치를 생성하여 test와 bugfixes를 하고 이상이 없다면 finish로 develop과 master에 merge 한 후 사라진다. 이후 해당 버전 번호에 맞는 숫자를 tag로 저장한다.

hofixes는 master에서 긴급하게 발견된 버그를 수정하기 위한 브랜치로 수정 후 develop과 master에 merge하고 사라진다.

"마치며"

Git Flow를 사용하면서 각 브랜치별로 Life Cycle이 존재하기 때문에 브랜치가 무분별하게 생성되어 쌓이는 일을 방지할 수 있었다. 또 이 시기에 배포 자동화에 대해 학습하였기 때문에 Develop을 Staging 환경에 활용하였고, Master는 Operate 환경에 활용하며 Git hooks을 이용해 배포 자동화 환경까지 구축하였다.

현재 나는 솔루션과 연구과제를 병행하는데 연구과제 프로젝트를 진행하면서 Git Flow와 Git hooks를 활용해 배포 자동화 환경 구축으로 낭비되는 시간을 많이 줄일 수 있었고 실제로 1월 중순까지 해야될 프로젝트를 80% 이상 진행될 수 있었다.

https://jfbta.tistory.com/266