[Git] Git branch 전략

유재민·2022년 6월 1일

필자는 이때까지 혼자서 개발을 해왔기 때문에 여러 branch를 생성할 필요가 없었다.
하지만, 추후에 회사에 입사하게 되었을 때 다른 개발자와의 협업 경험이 꼭 필요하다 느껴,
같은 앱을 같이 개발할 수 있는 동아리에 지원하고자 한다.
그렇기 때문에, 프로젝트를 진행하는데 문제가 없도록 Git branch 전략을 미리 공부하기로 했다.

🤷🏻‍♀️ Git branch 전략이란?

여러 개발자가 협업하는 환경에서 git 저장소를 효과적으로 활용하기 위한 work-flow

실무에서 협업을 진행하게 되면 동일한 소스코드를 모든 개발자가 함께 공유하고 다룬다.
기능을 개발하기도 하고 버그를 수정하거나 테스트를 진행하기도 한다.
동일한 코드로 시작을 했지만, 서로 다른 버전의 코드가 만들어지게 된다.
이렇게 동시에 각자 다른 작업들을 수월하게 진행하기 위해서 Git branch 전략을 사용한다.

Git Flow

5가지 브랜치를 이용해 운영하는 브랜치 전략
Brach
메인 브랜치: master, develop
보조 브랜치: feature, release, hotfix (merge 후 삭제)

1. feature

기능 구현 담당 브랜치
명칭 : feature/{구현기능명} (ex: feature/login - login 기능을 구현하는 브랜치)
develop 브랜치에서 생성되며, develop 브랜치로 merge됨
merge 후 삭제

2. develop

개발을 진행하는 중심적인 브랜치
명칭 : develop
feature에서 merge하며 살을 붙여나감
배포 가능한 수준일 때, release 브랜치로 merge 됨

3. release

배포를 위한 브랜치
명칭 : release-1 같은 방식으로 버전에 따른 릴리즈 지정
충분한 테스트와 버그 수정 후 master로 merge하여 배포
develop 브랜치에서 생성되며, 버그 수정 내용을 develop에도 반영함

4. hotfix

배포된 소스(master)에서 버그 발생 시 생성되는 브랜치
명칭 : hotfix-1
release에서 버그 검사를 했지만, 배포 후 예기치 못한 버그 수정
master 브랜치에서 생성되며, 수정 완료 시 develop, release, master 브랜치에 수정 내용 반영

5. master

최종적으로 배포되는 중심 브랜치
develop 브랜치에서 개발이 진행되어도 이전 release 브랜치 내용이 master에서 배포되어 있음
master 브랜치는 항상 실행 가능한 상태여야함

장단점

장점: 프로젝트 규모가 커질수록 소스코드를 관리하기 용이함
단점: 흐름을 복잡하게 만듬, release와 master의 구분이 모호함

Github Flow

Git Flow 브랜치 전략이 복잡하고 적용하기 어려워서 생겨난 브랜치 전략
master 브랜치 하나만을 가지고 pull request를 활용해 진행하는 방식

순서

master 브랜치에서 개발 시작
기능 구현 및 버그 발생 시 issue 작성
팀원들이 issue 해결을 위해 master 브랜치에서 생성한 feature/{구현기능명} 브랜치에서 개발을 하고 commit log 작성
push를 하면 pull request를 날릴 수 있음
pull request를 통해 팀원들 간의 피드백, 버그 찾는 과정 진행 (release 브랜치가 없으므로 이 과정이 탄탄하게 진행되야함)
모든 리뷰가 이루어지면, merge 전 배포를 통해 최종 테스트 진행
테스트 진행 완료 시 master 브랜치에 merge