Git Branch 전략

Branch 전략이란? 

Branch는 "분기"라는 뜻으로, 코드 작성을 위한 별도의 작업공간을 제공하는 수단으로 사용됨 

일반적으로 브랜치를 사용하면  다른 개발자의 분기에 영향을 주지않고 분리된 기능으로 관리되어,  

최종 작업 완료시 메인(마스터) 브랜치에 병합이 가능

즉 브랜치 전략은 소프트웨어 개발 팀이 코드를 작성, 병합 및 배포할 때 채택하는 전략을 의미 

 

Branch 전략의 목표

- 개발자 간의 적절한 조정을 통해 생산성을 향상

- 병렬 개발 체제를 활성화

- 계획적, 구조적 릴리스 단계를 구성

- 개발 워크플로를 방해하지 않으면서 문제를 신속하게 수정, 변경 가능하도록 함

 

Git Branch 전략이란? 

프로젝트의 Git 브랜치를 효과적으로 관리하기 위한 워크플로우 

Git 브랜치를 전략유형 4가지  :  Git Flow, GitHub Flow, GitLab Flow, Trunk-based development

 

Git 브랜치의 장점

- "가벼움"

- 데이터가 스냅샷으로 구성, 커밋할 때마다 Git이 그 순간의 파일 모양을 스냅샷으로 찍어 참조하여 저장 

- Git의 브랜치는 파일이 아닌 포인터라는 것

- 다른 VCS 툴에서는 파일 저장 방식 사용 , 중복 파일이 많을 수록 비효율적

- 이런 점에서 Git은 성능 측면과 공간 측면에서 매우 유리함 

 

1, Git Flow

Vincent Driessen이 2010년에 제시한 Git 브랜치 전략

- branching model을 적용해 고수준으로 저장소를 관리할 수 있게 해주는 확장 기능 

- branching model은 feature - develop(dev) - release - hotfix - master 단계로 브랜치를 나누어 코드를 관리하는 전략 

Git Flow

Git Flow의 5가지 브랜치 

- master(main) : 운영환경에 배포될 수 있는 브랜치

- develop : 다음 기능 버전이 담긴 브랜치

- feature : 새로운 기능을 개발하기 위한 브랜치

- release : 새로운 버전의 배포를 준비하는 브랜치

- hotfix : 운영환경에서 긴급한 버그 수정 작업 브랜치

 

항상 유지되는 주요 브랜치 : master, develop

일정 기간 동안만 유지되는 보조 브랜치 : feature, release, hotfix 

주요지점	기능 브랜치	릴리스 브랜치	핫픽스 브랜치
master main 브랜치  develop 브랜치 개발 코드 관리 master 브랜치에 병합, 새로운 버전 배포	feature 기능을 개발하는 브랜치  개발 완료 후 develop 브랜치로 병합	release 브랜치는 실제로 배포할 상태가 된 경우 생성 익숙한 버그를 수정하는 작업 등 develop 및 master로 병합	hotfix 배포 준비, 이미 배포한  제품이나 서비스 버그를 즉각 대응해야 할 때 사용  develop 및 master로 병합

 

2. GitHub Flow

GitHub를 기반으로 한 간단하고 유연한 개발 워크플로우

주요 목표 : 신속한 배포, 효율적인 협업 지원

GitHub Flow는 Git Flow와 달리 단일 브랜치를 사용하여 개발, 하나의 버전이 만들어지면 바로 배포 가능

GitHub 브랜치의 2종류 : master(main), feature

 

GitHub Flow

 

GitHub Flow 개발 과정

1. Branch 생성

- 새로운 기능이나 버스 수정 작업을 위한 새 브랜치 생성

- 개발 작업공간, 기능의 독립성 보장

2. Commit 작성

- 브랜치에서 변경 사항을 커밋으로 저장

- 커빗을 통해 코드 변경 내용 기록

3. Pull Request

- 변경 사항을 본래 브랜치로 병합하기 위해 풀 리퀘스트 생성

- 코드 검토, 토론, 테스트 수행

4. 리뷰 및 피드백

- 생성된 풀 리퀘스트를 바탕으로 다른 개발자들이 코드를 컴토, 피드백 제공

- 코드 품질 향상, 버그 발견 및 수정

5. merge 병합

- 풀 리퀘스트 승인 후 변경 사항을 본래 브랜치로 병합

- main 병합으 통해 작업한 내용이 다른 부분과 통합됨 

6. 배포

- 병합된 변경 사항은 배포를 위한 브랜치로 이동 

 

3. Git Flow & GitHub Flow  비교

	Git Flow	GitHub Flow
개념	main 브랜치와 develp 브랜치 두 축으로 구분	main 브랜치와 develp 브랜치 크게 구분하지 않음
브랜치종류	master develop(dev) feature release hotfix	master(main) feature
장점	브랜치 관리의 명확성 배포 안정성 협업 효율성 버전 관리와 롤백 유지 보수에 용이	간단하고 직관적 구조 지속적 배포 유연성과 빠른 피드백 충돌 최소화
단점	복잡성 다소 높은 진입장벽 느린 릴리즈 팀 규모에 대한 제한 유연성의 한계	대규모 프로젝트에 제한적 배포 위험성 배포 관리의 어려움
최적	규모가 큰(복잡한) 프로젝트 배포 주기가 잦지 않은 프로젝트 다양한 버전 관리가 필요한 모바일 애플리케이션	비교적 규모가 작은 프로젝트 잦은 배포 주기를 가지는 프로젝트 단일 릴리즈 버전만 존재하는 프로젝트

 

 

 

참고

https://onlyfor-me-blog.tistory.com/433

https://dahye-jeong.gitbook.io/git/git/2019-01-27-git-flow

https://velog.io/@jspp120/Git-Branch-%EC%A0%84%EB%9E%B5

https://velog.io/@gmlstjq123/Git-Flow-VS-Github-Flow