GIT 브랜치 전략

 

 

안녕하세요 웹 YB 김시연입니다.

매우매우 늦은 아티클 제출이지만 웨비톡 아티클을 겸사겸사 올립니다ㅎ,,

 

이번 웨비톡 발표 흐름은

0. 인트로
1. 협업 중 흔한 문제
2. 브랜치 전략 소개
3. 충돌 방지 실전 팁
4. 충돌 발생시 해결법
5. GUI 툴 활용
6. 마무리

 

이런 식으로 구성할까 싶습니다...!

아티클은 이 중에서 (모든 게 저에게는 꽤 어렵지만) 제일 새롭고 잘 모르는 깃 브랜치 전략에 대해 작성하게 되었습니다. 

 

 

🤔 Git Branch 전략이 뭘까?

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

쉽게 말해, Git Branch들에 전략, 즉 규칙을 부여하는 것!

브랜치 생성에 규칙을 만들어서 협업을 유연하게 하는 방법론

각 branch는 어떤 branch를 생성할지, 어디에서 생성할지 (분기할지), 어디로 병합할지 등

 

각 브랜치에 규칙을 정해놓고, 해당 규칙을 팀 내에서 지켜가며 개발을 진행하는 것이다.

 

 

지난 합동 세미나에서 뭔지도 모르고 일반적인 브랜치 전략(?)을 사용했는데

사실 잘 모르고 그냥 많이들 사용하는 것 같아서 따라갔었다,, 뭔지도 잘 모르는데 찾아보지 않고 넘긴 걸 반성한다..

 

만약 브랜치 전략이 없다면 어떻게 될까? 아래와 같은 문제 상황이 발생할 것이다.

어떤 브랜치가 최신 브랜치인지 헷갈림
어떤 브랜치를 끌어와서 개발을 시작해야 할까?
어디에 push를 보내지?
배포 버전은 어떤 걸 골라야 하지?

 

위와 같은 상황을 최소화하기 위해 사용하는 것이 브랜치 전략

 

 

필자는 가장 널리 사용되는 2가지 브랜치 전략 git-flow, github-flow을 정리하려고 한다

 

 

1. git-flow 전략

Git Flow는 Vicent Driessen이 (무려) 2010년에 제시한 Git 브랜치 전략이다.

https://nvie.com/posts/a-successful-git-branching-model/

 

 

위 그래프에서 한 줄이 브랜치 하나를 의미하는데 각 브랜치에 적용된 규칙과 전략을 설명하자면

 

• master: 라이브 서버에 제품으로 출시되는 브랜치
• develop: 다음 출시 버전을 대비하여 개발하는 브랜치
• feature: 추가 기능 개발 브랜치, develop 브랜치에 들어간다.
• release: 다음 버전 출시를 준비하는 브랜치. develop 브랜치를 release 브랜치로 옮긴 후 QA, 테스트를 진행하고 master 브랜치로 합친다.
• hotfix: master 브랜치에서 발생한 버그를 수정하는 브랜치 (배포한 버전에서 긴급하게 수정할 필요가 있을 때 master 브랜치에서 분리하는 브랜치)

메인 브랜치는 master 브랜치와 develop 브랜치 두 종류를 말한다!

master 브랜치는 배포 가능한 상태만을 관리하는 브랜치 / develop 브랜치는 다음에 배포할 것을 개발하는 브랜치

develop 브랜치가 통합 브랜치 역할을 하며, 평소에는 이 브랜치를 기반으로 개발을 진행한다.

 

이 과정이 좀 더 자세히 잘 정리되어 있는 아티클: https://inpa.tistory.com/entry/GIT-%E2%9A%A1%EF%B8%8F-github-flow-git-flow-%F0%9F%93%88-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EC%A0%84%EB%9E%B5

 

이 전략의 전체 흐름

1. 신규기능 개발

• 개발자는 develop 브랜치로부터 본인이 신규 개발할 기능을 위한 feature 브랜치를 생성한다.
• feature 브랜치에서 기능을 완성하면 develop브랜치에 merge를 진행하게 된다.

2. 라이브 서버로 배포

• feature 브랜치들이 모두 develop 브랜치에 merge 되었다면 QA를 위해 release 브랜치를 생성한다.
• release 브랜치를 통해 오류가 확인된다면 release 브랜치 내에서 수정을 진행한다.
• QA와 테스트를 모두 통과했다면, 배포를 위해 release 브랜치를 master 브랜치 쪽으로 merge하며, 만일 release 브랜치 내부에서 오류 수정이 진행되었을 경우 동기화를 위해 develop 브랜치 쪽에서도 merge를 진행한다.

3. 배포 후 관리

• 만약 배포된 라이브 서버(master)에서 버그가 발생된다면, hotfix 브랜치를 생성하여 버그 픽스를 진행한다.
• 그리고 종료된 버그 픽스를 master와 develop 양 쪽에 merge하여 동기화시킨다.

 

💫 장점

• QA/테스트/릴리즈 준비 흐름이 명확
• 릴리즈 관리가 쉬움 (태그, 히스토리 분리)

💥 단점

• 브랜치가 많아 복잡하고 무겁다
• 빠른 배포 주기(=CI/CD 환경)와는 안 맞음

🤟 추천 상황

모바일 애플리케이션의 경우 다양한 버전이 존재하고, 롤백이 잦다. 

반면 웹 애플리케이션은 배포하는 동안 항상 최신 버전으로 유지하며 롤백보다는 버그를 수정하는 일이 많다.

따라서 Git Flow는 모바일 애플리케이션 개발에 적합한 Flow이다.

롤백이란?

 

2. github-flow 전략

 

GitHub에서 제안한 전략으로, 단순하고 빠른 배포 주기를 전제로 한다. CI/CD 환경, 애자일 개발에 적합한 전략이다. 

Github Flow에는 브랜치가 2개밖에 존재하지 않는다. 

https://docs.github.com/en/get-started/using-github/github-flow

 

main             ← 항상 배포 가능한 상태 유지
├── feature/login   ← 기능 개발 브랜치

 

Github Flow는 main 브랜치만 엄격한 규칙을 적용하고, 나머지 브랜치는 별다른 규칙이 존재하지 않는다.

*main을 제외한 나머지 하나의 브랜치는 자유롭게 생성 가능

 

• main: 언제든 배포가 가능한 상태를 유지해야 한다. main으로 merge하기 전에는 엄격한 테스트를 거쳐야 한다. (CI 필수)
• 나머지 브랜치 하나: main에서 생성하며 이름, 규칙 등 자유롭게 결정한다. 이때 브랜치명과 커밋 메시지에는 어떤 일을 하고 있는지 자세하게 작성해야 함.

이 전략의 전체 흐름은 다음 사진과 같다

 

1. main에서 새로운 branch를 생성한다. 이때 브랜치 명은 어떤 일을 할지 자세하게 작성한다.

2. 생성한 브랜치에서 작업이 끝나면 main으로 PR을 작성한다.

3. PR 리뷰가 끝나고 main으로 merge할 때 CI/CD를 거쳐서 배포를 진행한다.

 

위에서 살펴본 Git Flow보다 이해하기 훨씬 쉽고 간단하다!!

 

💫 장점

• 단순하고 실용적
• 자동 배포(CI/CD)에 최적
• Pull Request 중심 협업에 매우 적합
•  

💥 단점

• QA 브랜치 없음 → 테스트 문화나 자동화가 반드시 필요
• 릴리즈 관리가 Git Flow보다 명확하지 않음

 

---

 

git-flow 특징

• 규모가 큰 프로젝트에서 적합 (브랜치 수가 많고 여러 규칙이 있기 때문)
• 배포 주기가 잦지 않은 프로젝트
• 다양한 버전 관리가 필요한 모바일 애플리케이션

 

github-flow 특징 

• 규모가 적은 프로젝트에서 적합
• 수시로 배포가 일어나서 잦은 배포 주기를 가지는 프로젝트에 적합
• git에 익숙하지 않은 사람이 있을 때 경험해보기 좋다

 

	Git Flow	GitHub Flow
구조 복잡도	복잡	간단
배포 주기	길다 (릴리즈 단위)	짧다 (상시 배포)
브랜치 종류	main, develop, feature, release, hotfix	main, feature
사용 대상	대기업, 릴리즈 관리 중요한 팀	스타트업, 빠른 피드백 지향 팀
CI/CD 연계	어려움	적합

 

 

 

 

마무리하며..

 

이전에 찍먹 프로젝트에서 Git Flow 방식, 최근 합동세미나에서 Github Flow 방식을 사용한 것 같아서

나름 2가지 모두 경험해보게 된 것 같은데(?) 확실히 후자가 이해하기도 쉽고 사용할 때도 편리한 것 같다..

프로젝트의 규모나 상황에 맞춰 어떤 브랜치 전략을 사용하면 좋을지 이해할 수 있었다!

 

 

 

 

 

참고

https://ksh-coding.tistory.com/109

https://inpa.tistory.com/entry/GIT-%E2%9A%A1%EF%B8%8F-github-flow-git-flow-%F0%9F%93%88-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EC%A0%84%EB%9E%B5