[Git] 브랜치 전략

박상혁·2023년 5월 9일

Git

목록 보기

2/2

개요

깃 기초 사용법에 이어 효율적인 개발을 위해 깃 브랜치에 대한 기초 이론 및 현업에서 사용하는 기초 브랜치 전략에 대하여 알아보겠습니다.

본론

1. 개요

혼자서 개발하는 것보다 여럿이서 함께 구역을 나누어 개발하는 것이 훨씬 효율이 좋습니다. 하지만 협업 단계에서 코드가 뒤엉키게 되어 에러가 남발하는 사태가 발생할 수 있습니다.
이를 위해 협업 과정의 질서(?)가 필요해졌습니다.

브랜치는 독립적으로 어떤 작업을 진행하기 위한 가지입니다. 다른 브랜치와 영향을 끼치지 않으며 혼자서 수행이 가능합니다.

개발자들은 각자 독자적인 로컬 브랜치를 생성하여 작업을 수행한 뒤 나중에 메인 브랜치의 버전 코드와 비교하여 병합하는 과정을 거칩니다.

2. master 브랜치

깃은 최초로 master 브랜치를 생성합니다.
git init이나 clone을 통해 깃 저장소가 최초로 만들어지면
master라는 이름의 브랜치를 생성합니다. 이때부터 모든 작업은 master 브랜치로 이루어집니다.

master라는 이름보단 main이란 이름이 가독성 면에서 더 좋기 때문에 master 브랜치의 이름을 수정합니다.

git branch -M main

이후 main이란 이름으로 작업을 수행합니다.

3. 깃 브랜치 전략 (git flow)

각 브랜치마다 역할을 나누어서 구별하여 개발을 진행하면 훨씬 안정적으로 개발을 진행할 수 있습니다.

Vincent Driessen - A successful Git branching model
2010년 Vincent Driessen의 블로그에 소개된 git flow 전략이 인기를 끌며 대중적으로 전파되었습니다. 해당 모델을 바탕으로 기초 브랜치 전략을 소개하고자 합니다.

크게 3가지의 브랜치로 나눕니다.

main
develop
supporting

여기서 supporting branch는 또 3가지의 브랜치로 나뉩니다.

feature
release
Hotfix

총 5가지의 브랜치로 나눠집니다.

이중 main과 develop 브랜치는 항시 유지하며, supporting 브랜치는 merge 직후 삭제합니다.

👉 main branch
라이브 서버에 배포 가능한 상태(snapshot)만을 관리하는 브랜치입니다.

👉 develop branch
다음 배포할 것을 개발하는 브랜치입니다.

👉 feature branch
하나의 기능을 개발하기 위한 브랜치입니다.
develop 브랜치에서 뻗쳐나가며 develop에 다시 머지하는 방식으로 진행됩니다.
feature-네이밍

👉 release branch
배포 준비를 위한 브랜치입니다.
버전 수정, 이름 변경 등 소소한 데이터수정 및 버그 픽스 등을 수행하며 main 브랜치로 가기위한 최종 관문이라 생각하면 됩니다.
release-네이밍

👉 Hotfix branch
배포 후 main 브랜치에 있는 상태에 버그가 발생했을 때 해당 브랜치에서 버그를 수정하여 main에 재배포합니다. develop에도 똑같이 해당 수정된 버전을 올립니다.
hotfix-네이밍

이렇게 5가지의 브랜치로 나눔으로써 각자 개발 역할을 나누어 각각의 작업에 구애받지 않고 병렬적으로 수행할 수 있습니다.

git flow를 활용한 전반적인 개발 프로세스는 총 3단계로 나눌 수 있습니다.

신규 기능 개발
라이브 서버 배포
배포 후 관리

4. github 브랜치 전략(github flow)

직전의 git flow 전략은 다양한 버전을 기록할 수 있으며 긴 시간동안 개발, hotfix 등을 수행할 수 있는 전력을 가진 팀이 있다면 효율적입니다.

하지만 웹 어플리케이션을 개발할 때에는 항상 최신의 단일 버전만을 필요로 하기 때문에 다양한 버전을 기록할 필요가 없어졌습니다.
이에 더 단순한 work flow를 찾게 되었고 github flow를 사용하게 되었습니다.

SCOTT CHACON - GitHub Flow
2011년 scott chacon이 처음 github flow를 발표하였습니다.

github flow는 git flow보다 훨씬 간단한 flow를 가집니다.
다음과 같은 단계로 나누어집니다.

브랜치 생성
커밋 및 푸쉬
PR 생성 및 리뷰
테스트
최종 Merge

👉 브랜치 생성
브랜치를 생성합니다. git flow와 달리 hotfix, develop, feature 등을 구분하지 않습니다. 이에 브랜치 네이밍을 의도에 맞게 잘 만들어야 합니다.

👉 커밋 및 푸쉬
해당 브랜치에서 개발을 진행하고 커밋 및 푸쉬까지 이루어집니다.

👉 PR 생성 및 리뷰
Pull Request를 생성합니다. 이는 main 브랜치에 merge되기 전 최종 관문으로 다른 사람들에게 코드 리뷰를 받으며 수정하는 단계를 거칩니다.

👉 테스트
라이브 서버에 배포 후 테스트를 진행합니다. 이 단계에서 버그를 수정합니다.

👉 최종 Merge
최종적으로 main 브랜치에 머지합니다.
해당 단계에서 main으로 브랜치에 merge하게 되면 CI/CD 환경을 구축하여 즉시 라이브서버에 배포되도록 합니다.

5. 전략 선택

git flow와 github flow는 어떤 경우에 사용되어야 할까요

우선, git flow를 사용해서 웹 어플리케이션을 개발해도 상관은 없습니다. 충분히 개발 가능합니다. 상황에 맞게 전략을 선택하면 더 효율적인 개발을 수행할 수 있습니다.

1개월 이상의 긴 호흡으로 개발하여 주기적으로 배포, QA 및 테스트, hotfix 등 수행할 수 있는 여력이 있는 팀이라면 git-flow가 적합하다
출처: 현구막 - 깃 브랜치 전략

개발팀이 소규모 애자일 팀이고, 제품이 단일 릴리즈 버전밖에 존재하지 않는다면 Github Flow가 적절하다. 대부분의 웹 애플리케이션은 여러 버전을 관리하지 않고, 가장 최신 버전 하나만을 사용자가 사용하게 된다.
Github Flow는 하루에 변경사항을 작은 단위로 신속하고 자주 병합/배포 할 수 있는 구조로, 진정한 의미의 CI/CD를 실천하기 적합한 브랜치 전략이 아닐까한다.
출처: hudi - Git 브랜치 전략 (feat. Git Flow, Github Flow)

요약 및 결론

요약
브랜치 전략을 적극 활용하자.

지금까지는 프로젝트를 진행할 때 git을 사용하면서 단순히 원격저장소에 내 코드를 편하게 올릴 수 있다라는 것만을 장점으로 생각하며 사용해왔는데,
브랜치에 대해 알아보고 다양한 전략들을 공부함으로써 훨씬 더 효율적으로 프로젝트를 운영하며 시간을 아낄 수 있는 방법이 있는 것을 알게 되었습니다.