Git_Git Flow 브랜치 전략

송민혁·2023년 9월 14일

branch git

Git

목록 보기

4/6

Git Branch 전략

브랜치 전략이란 여러 개발자가 하나의 저장소를 사용하는 환경에서 저장소를 효과적으로 활용하기 위한 work-flow이다.

브랜치 전략의 역할로서는 브랜치의 생성, 삭제, 병합 등 git의 유연한 구조를 활용해서 각 개발자들의 혼란을 줄이면서 소스를 관리를 한다.

브랜치 전략은 브랜치 생성에 규칙을 만들어서 협업을 유연하게 하는 방법론이다.

브랜치 전략이 없다면?

어느 branch가 최신이지?
어느 branch를 끌어와야 하지?
배포 버전은 어떤 걸로 해야 하지?
어디에 머지하지?
핫픽스를 해야 하는데 어떤 브랜치를 기준으로 하지
...

수많은 고민들로 시간을 허비할 것이다. 그래서 개발자들끼리의 협업 규칙이 필요한 것이다.

종류

가장 널리 사용되는 2가지 브랜치 전략에 대해 알아보자

브랜치 전략의 많이 쓰이는 2가지 종류

github-flow 전략

git-flow 전략

Github Flow

단순한 구조부터 살펴보자.

Github-flow는 마스터 브랜치와 Pull request를 활용한 단순한 브랜치 전략이다.

Github-flow 전략은 기능 개발, 버그 픽스 등 어떤 이유로든 새로운 브랜치를 생성하는 것으로 시작된다.
단, 이때 체계적인 분류 없이 브랜치 하나에 의존하게 되기 때문에 브랜치 이름을 통해 의도를 명확하게 드러내는 것이 매우 중요하다.

특징

새로운 브랜치는 항상 마스터 브랜치에서 만든다.
마스터 브랜치를 중심으로 운영되며, 기능 개발 버그 수정 등의 작업용 브랜치를 구분하지 않는 단순한 구조이다.
수시로 배포가 일어나는 프로젝트에 유용하다.
git-flow 전략과 다르게 feature 브랜치나 develop 브랜치가 존재하지 않는다.

단계

브랜치 생성 : Master로부터 기능 추가
기능 개발, 버그 수정
Pull Request 생성 : 기능 또는 오류 수정이 완료되었으면 PR을 보낸다.
리뷰와 논의
공개 및 테스트 : github에서는 Master에 합치기 전에 브랜치에서 코드를 공개 및 테스트를 할 수 있다.
합치기 (Merge)

PR이란
피드백이나 도움이 필요할 때 그리고 merge 준비가 완료되었을 때는 Pull Request를 생성한다.

PR은 코드리뷰를 도와주는 시스템

Git Flow

Github flow와 다르게 크게 5가지의 브랜치를 운영하며 관리를 한다.
5가지 중, 항시 유지되는 메인 브랜치 master, develop 2가지와 merge 되면 사라지는 보조 브랜치 feature, release, hotfix 3가지로 구성된다.

대부분의 작업은 develop에서 취합한다 생각하면 되며 테스트를 통해 정말 확실하게 더 이상 변동사항이 없다 싶을 때 master로의 병합을 진행하게 된다.
master가 아닌 가지들은 master의 변동사항을 꾸준히 주시해야 한다.
배포 주기가 길고 팀의 여력이 있는 경우에 적합하다.
보조 브랜치들은 메인 브랜치와 다르게 사용을 마치면 브랜치를 삭제한다.

용어

메인 브랜치

master : 라이브 서버에 제품으로 출시되는 브랜치 (프로덕션)
develop : 다음 출시 버전을 대비하여 개발하는 브랜치

보조 브랜치

feature : 추가 기능 개발 브랜치 (develop 브랜치에 들어간다)
(분기되는 곳: develop, 머지하는 곳: develop, 이름 설정: master, develop, release-, hotfix-를 제외하기만 하면 자유롭게 이름 설정이 가능 )
release : 다음 버전 출시를 준비하는 브랜치
(분기되는 곳: develop, 머지하는 곳: develop & master, 이름 설정: release-*)
hotfix : master 브랜치에서 발생한 버그를 수정하는 브랜치
(분기되는 곳: master, 머지하는 곳: develop & master, 이름 설정: hotfix-*)

주의 사항

feature 브랜치를 develop 브랜치에 머지할 때는 --no-ff를 사용하여 기록을 그룹화한다.

`--no-ff를 사용하지 않으면?
Fast-forward 관계 (rebase를 한 상태)에서 브랜치의 존재 여부를 몰라서 어떤 커밋으로부터 해당 기능을 구현했는지 확인하기 어렵다.
release 브랜치를 develop & master에 머지할 때도 --no-ff를 사용하여 기록을 그룹화한다.
hotfix를 master 브랜치에 머지할 때 태그 명령을 통해 이전 버전보다 높은 버전을 명시한다.
ex) 2.6 -> 2.6.1