[Git] Git 브랜치 전략

Git 브랜치 전략이란

브랜치 전략이란 여러 명의 협업자가 Git의 브랜치를 사용해 하나의 공동 저장소를 효율적으로 사용하기 위한 전략이다.

 

브랜치 전략을 세우지 않고 개발하면

• 체계 없는 브랜치 생성과 병합
• 중구난방 흩어진 이슈와 커밋
• 그에 따른 협업의 어려움

의 문제가 발생할 수 있다.

 

대표적인 브랜치 전략들인 Git Flow 와 Github Flow 를 살펴보고자 한다.

 

Git Flow

Git Flow 는 브랜치를 크게 5가지 목적으로 나누어 개발한다.

 

master

최종으로 배포되는 브랜치. 배포 후 버전 태그(v1.0, v1.1 등) 를 추가한다.

 

release

배포하기 전 QA를 진행하는 브랜치. develop 브랜치에서 생성되고 QA에 통과하면 master 브랜치에 머지한다. 수정 사항이 있다면 master 와 develop 브랜치에 반영한다. 이후 사용하지 않을 것이라면 삭제해도 무관하다. 보통 release-* 으로 네이밍하고 * 자리에는 숫자나 버전을 붙인다.

 

develop

개발할 때의 메인 브랜치. 구현해야하는 기능이 있을 때 feature 브랜치를 생성해 개발하고, 구현 완료 후 develop 브랜치로 병합한다. 다음 배포 버전 분량까지 개발 완료 후 QA 테스트를 위해 release 브랜치로 머지된다.

 

feature

이슈 및 기능 구현을 위해 생성하는 브랜치. develop 브랜치에서 생성한다. 기능 구현 완료 후 develop 브랜치에 머지한 뒤 feature 브랜치는 삭제한다. 보통 feature/기능명 으로 네이밍한다.

feature 브랜치로 분기함으로써 여러 사람이 한 브랜치를 건드려 충돌날 일이 없어져 기능 구현에 집중할 수 있다. 또 기능 구현 도중 이전 버전으로 되돌아가야할 일이 생겼을 때 develop 브랜치를 다시 받아 해결할 수 있다.

 

hotfix

배포 후 release 브랜치에서 미처 발견하지 못한 버그가 발생해 긴급히 수정해야할 때 생성하는 브랜치. master 에서 생성하고 수정 후 master 와 develop 브랜치에 반영하고 hotfix 브랜치는 삭제한다. 보통 hotfix-*로 네이밍하고 * 자리에는 숫자나 버전을 붙인다.

hotfix 브랜치로 분기함으로써 버그 수정 중에도 개발자들은 develop 브랜치에서 영향 없이 개발할 수 있다.

1. 맨 처음 master 브랜치를 생성한다.
2. 버전 0.1(초기 상태) 개발을 위해 develop 브랜치를 생성한다. develop 브랜치에는 버그 수정 커밋이 상시로 추가된다.
3. 기능 구현을 해야할 경우 develop 브랜치에서 feature 브랜치를 생성해 분기한다.
4. 구현 완료된 feature 브랜치는 동료 혹은 검토자에게 검토 후 develop 브랜치로 머지된다.
5. 다음 릴리즈의 모든 기능 구현이 완료되면 develop 브랜치의 내용을 release 브랜치로 머지한다.
6. release 브랜치에 버그 수정 커밋이 추가되고, 버그 수정이 완료되면 develop 브랜치와 master 브랜치에 머지한다.
7. master 브랜치는 반영된 내용을 버전 태그를 달아 배포한다. (version +1)
8. 배포 후 발견된 버그는 긴급 수정을 위해 hotfix 브랜치를 생성해 수정한다.
9. hotfix 브랜치에서 수정이 끝나면 develop 브랜치와 master 브랜치에 반영하고 버전 태그를 달아 배포한다. (version +0.1)

Git Flow 전략은 배포, 테스트, 개발, 기능구현, 버그수정 등을 확실히 분리하여 큰 프로젝트에 적합한 전략이다. 그러나 관리할 브랜치가 상대적으로 많은 점, master 와 release 브랜치의 경계가 모호한 점 등의 이유로 Github 나 소규모 프로젝트에 적용하기엔 복잡하다. 이에 Git Flow 를 간편화한 Github Flow 전략이 나왔다.

 

Github Flow

소규모 프로젝트, 배포자동화가 된 Github 등의 프로젝트에 Git Flow 를 적용하기 복잡해 그 흐름을 간편화한 Git 브랜치 전략이다.

 

master 브랜치를 메인으로 두고 기능 구현, 버그 수정 등의 변경 사항을 모두 master 브랜치에 머지한다.

 

핵심은 머지하기 전 pull request 를 통한 코드 리뷰로 문제사항을 꼼꼼히 확인하고 배포 전 라이브 서버에서 테스트하는 것, 머지 후 배포가 자동으로 이루어지는 것이다.

 

1. master 브랜치를 생성한다.
2. 기능을 구현해야하거나 버그가 발생하면 이슈를 작성한다.
3. 개발자들은 이슈 해결을 위해 feature 브랜치를 생성하고 커밋 메시지를 상세히 남긴다. 또 로컬 작업 내용이 날아가거나 이전 내용으로 돌아갈 일이 있을 때를 대비하여 원격 브랜치에 수시로 push 해준다.
4. 기능 구현 혹은 버그 수정이 완료되면 pull request 를 날린다. 팀원들 혹은 검토자는 pull request 를 보고 코드 리뷰를 한다. release 브랜치가 없으므로 꼼꼼히 피드백해야 한다.
5. 리뷰가 끝나면 머지하기 전 라이브 서버 혹은 테스트 서버에서 최종 테스트를 진행한다. 배포시 문제가 발생하면 master 브랜치의 내용으로 다시 배포한다.
6. 문제가 없다는 것을 확인했으니 master 브랜치로 머지한다. 이때 배포는 자동으로 즉시 배포되어야 한다.

 

Github Flow는 관리할 브랜치가 적어 적용하기 쉽지만 프로젝트 규모가 커지면 치명적인 문제가 발생할 수 있다. 따라서 수시로 배포되어야 하는 소규모 프로젝트에 적합하다.