Git 브랜치 전략

브랜치를 쓰는 이유

프로젝트를 시작하고 깃으로 버전을 관리하며 다른 개발자와 협업한다.

만약 브랜치가 기본 브랜치인 Main 브랜치만 존재한다면,
모두가 main 브랜치에 자신들의 작업을 수정, 추가, 삭제하게 될 것이다.

이로 인해 여러 문제가 발생하게 되며 아래와 같은 예시를 볼 수 있다.
1.배포된 main 브랜치는 불완전한 상태가 된다.
2.다른사람의 작업중인 파일을 건들일 수 있다.
3.개발 과정 히스토리가 뒤죽박죽 섞인다. -> 원하는 시점으로 롤백이 어렵다.

이런 문제들을 해결하려면 브랜치를 만들어 독립적인 환경을 만들어주면 된다.
(Ex.기능 개발 브랜치, 버그 수정 브랜치, 테스트 브랜치 등)

즉, 브랜치를 통해서 병렬적으로 프로젝트 개발을 할 수 있다.

Git 브랜치 전략

브랜치를 어떤 식으로 만들어야 할까?
브랜치를 너무 중구난방으로 만들어 낸다면 사용자에게 혼란을 야기할 수 있다.

-어떤 브랜치가 최신 브랜치지?
-어떤 브랜치를 끌어와서 개발을 시작해야 하지?
-어디에 Push를 보내야 하지?
-핫픽스를 해야하는데 어떤 브랜치를 기준으로 수정해야할까?
-배포 버전은 어떤 걸 골라야하지?
-내가 만든 브랜치는 어디에 병합해야하지?

위와 같은 혼란들은 프로젝트를 진행하는데 수많은 걸림돌이 될 것이다.

이를 해결하기 위해 Git 브랜치 전략(브랜치를 효과적으로 관리)이 탄생했다.
직접 브랜치 전략을 만들어도 무방하며, 이미 검증된 좋은 전략들이 있다.
그 중 Git flow 와 GitHub flow 브랜치 전략을 알아보자.

1. Git flow

크게 메인 브랜치와 서브 브랜치로 나눈다.

메인 브랜치 : Main, Develop
서브 브랜치 : Featur, Release, Hotfix

총 5가지 브랜치로 프로젝트를 관리한다.

Main : 라이브 서버에 제품으로 출시되는 브랜치
프로젝트 시작 시 기본 브랜치, 배포 가능한 상태 유지 필요.

Develop : 다음 출시 버전을 개발하는 브랜치
개발이 완료되면 Release 브랜치로 머지 된다.

Feature : 추가 기능 개발 브랜치.
Develop 브랜치에서 생성되고, 기능 개발 완료하면 Deveop 브랜치로 머지된다.

Release : 개발된 다음 버전을 출시 준비하는 브랜치
마지막 Test를 진행 후, Main & Develop 브랜치에 머지한다.

Hotfix : 배포된 Main브랜치에 버그 발생 시 수정하는 브랜치
Main 브랜치에서 생성하며, 문제 해결 완료되면 Main & Develop 브랜치에 머지한다.

2. GitHug flow

매우 간단한 구조
브랜치를 두개만 운용하여 간단하며 빠르게 수정 배포할수 있는 전략.

Main : 라이브 서버에 제품으로 출시되는 브랜치
프로젝트 시작 시 기본 브랜치, 배포 가능한 상태 유지 필요.

Topic : 기능 개발, 버그 수정, 테스트 등 모든 역할을 하는 브랜치
1. 모든 역할을 하기에 브랜치명을 명확하게 할 필요가 있다.
2. 수시로 원격 브랜치에 Push할 필요가 있다. (타 개발자에게 알리기 위함)
3. 작업 완료 후 Pull Request를 통해 Main 브랜치에 머지한다.

Git flow VS GitHub flow

두 전략의 차이는 프로세스를 어떻게 나누느냐의 차이로 볼 수 있다.

상대적으로 길고 더욱 안전하게 서비스를 배포하기 위해서는 Git flow가 적절할 것이고
신속하고 자주 병합/배포를 해야한다면 GitHub flow가 적절할 것이다.

끝으로

브랜치 전략을 알아보기 위해 예시 2개를 보여주었고 간단히 비교를 했다.
프로젝트마다 혹은 팀마다 어울리는 전략이 있을 것이며
스스로 전략을 구축해도 좋고 Gitlab flow, Trunk-based Development 등과 같은
많은 전략이 있다는 것을 알아두어야 한다.