GIT 브랜치 전략이란

GIT 브랜치 전략이란?

브랜치 전략은 여러 개발자가 협업하며 하나의 저장소를 사용하는 환경에서 저장소를 효과적으로 사용하기 위한 워크플로우. 즉, 브랜치 생성에 규칙을 만들어 협업을 유연하게 해주는 방법론

개발시에 브랜치 전략이 꼭 필요할까? 

메인 브랜치에서만 작업하는 경우에 하나의 기능을 개발하기 위해 여러 개의 커밋을 한다면, 해당 기능이 완성되기 전까지 메인 브랜치의 코드는 불완전한 상태로 있게된다. 협업을 하는 프로젝트라 생각해보면, 내가 작업 중인 파일을 누군가 건드려 개발한다면 히스토리가 메인 브랜치에 섞여 구분이 어렵다. 브랜치 기능을 사용하면 다른 브랜치에 영향을 받지 않고 독립적인 환경에서 기능을 개발할 수 있어 여러 기능을 여러 사람이 독립적으로 개발할 수 있게 되어 협업시 필수적으로 사용되는 기능이다. 

가장 많이 사용되는 2가지 브랜치 전략인 Git-flow와 Github-flow

 

1. Git-Flow

Git Flow에서는 항상 유지되는 메인브랜치인 master와 develop, 일정 기간 유지되는 보조 브랜치인 feature, release, hostfix의 5가지의 브랜치를 사용

1. master : 제품으로 출시 될 수 있는 브랜치
2. develop : 다음 출시 버전을 개발하는 브랜치 (develop 브랜치를 기반으로 개발 진행)
3. feature : 기능 개발용 브랜치
4. release : 이번 출시 버전을 위한 브랜치(제품을 배포하고자 할 때 사용)
5. hotfix : 출시 버전에서 발생한 긴급한 버그를 수정하는 브랜치

 

보조 브랜치(Feature)

 

• 새로운 기능 추가시 feature 브랜치 생성(develop브랜치에서 뻗어나와서)
• 기능 개발 완료 후, develop 브랜치로 merge
• develop : 기존에 잘 동작하는 코드가 모여있는 브랜치
• feature : 각각의 기능에 따라 브랜치를 분리해서 갖고 있는 브랜치
• 브랜치 이름 : feature/기능요약의 형식을 추천 (ex. feature/login)

 

릴리즈 브랜치(Release)

 

• 배포를 위한 최종적인 버그 수정 등의 개발을 위한 브랜치
• 배포 가능한 상태가 되면 master브랜치로 merge하고, 출시된 master 브랜치에 버전 태그를 추가
• release 브랜치에서 기능을 점검하며 발생한 수정사항은 develop에도 merge

 

핫픽스 브랜치(Hotfix)

• 배포한 버전에서 긴급하게 수정이 필요할 때, master 브랜치에서 분리하여 만드는 브랜치
• 수정 후, develop, master 브랜치에 merge

 

장점

• 브랜치별로 역할을 명확히 나누는 규칙성
• 디테일한 버전의 정보 제공
• master 브랜치의 코드는 테스트 후 최종 수정된 것만 반영하기에 깔끔한 상태 유지

 

2. Github-Flow

Git Flow가 다소 복잡하여 만들어진 새로운 관리 방식

 

• 체계적인 브랜치 분류가 없기 때문에 브랜치 이름을 통해 의도를 명확하게 드러내는 것이 중요
•  master 브랜치에 대한 규칙만 있다면 나머지 브랜치들에 대해서는 특별히 관여하지 않으며, pull request 기능을 사용할 것을 권장

 

Github-Flow 흐름

1. 개발을 진행하며 커밋 메시지를 명확하고 상세하게 작성

2. 작업 완료 후 PR을 생성하여 코드 리뷰와 테스트를 거친 후, master 브랜치로 merge

3. GIthub-flow에서는 master 브랜치가 가장 최신 브랜치이기에, 배포 자동화 도구를 통해 즉시 배포

 

Git-Flow vs Github-Flow 

 

• 프로젝트의 규모가 커지면 커질수록 소스코드를 관리하기에 용이한 git-flow

• 수시로 릴리즈 되어야 하는 서비스를 개발한다면, 간단한 워크플로우인 github-flow가 적절