[git] 브랜치 전략

강신현·2022년 9월 6일

[프로젝트] PlevUp

목록 보기

2/3

필요성

이전 프로젝트에서는 개인 마다 구현해야 하는 기능들을 할당하고
개인 전용 브랜치를 하나 생성하여 사용하고 기능 구현이 완료될 때마다 main 에 pull request를 하는 방식으로 진행했었다.

하지만 각자 구현 기능들을 할당하기 때문에 크게 번거로움은 없었지만
따로 checkout 할 필요 없이, 각자의 브랜치에서만 코딩을 했었기 때문에
서로 구현하는 기능과 자기가 구현하고 있던 기능이 서로 영향이 있을 경우에 상대방의 브랜치로 checkout 할 때 많이 신경이 쓰였다.

또한 기능 하나 당 한 사람이 전담으로 맡지 않고 두사람이 동시에 개발을 할 때 누구의 브랜치에서 진행을 할지 등 애매한 부분이 많았고
이러한 이유로 git branch 전략에 대해 찾아봤고 이번 프로젝트에서는 새로운 전략을 적용해보기로 했다.

명명 규칙 및 전략

꼭 이렇게 브랜치를 관리해야 하는 것은 아니지만 사람들이 통상적으로 많이 사용하는 전략인 만큼
많은 개발자와 함께 협업을 해야하는 프로젝트에서의 유용성은 어느정도 검증이 되었다고 생각했다.

브랜치의 구조는 다음과 같다.

Master branch

Develop branch

Feature branch

Release branch

Hotfix branch

1. Master branch

Release(배포)출시 할 수 있는 브랜치

최종 배포(Release) 이력을 관리하기 위한 최상위 브랜치로, 배포 가능한 상태만을 관리한다.

2. Develop branch

다음 출시 버전을 개발하는 브랜치

Master에서 분리되어 기능 개발을 위한 브랜치들을 병합하기 위해 사용한다.
모든 기능의 개발이 완료 및 버그가 수정되어 배포 가능한 상태가 되면 Develop 브랜치를 Master 브랜치에 병합(merge) 한다.

3. Feature branch

기능을 개발하는 브랜치

Feature 브랜치에서의 작업은 기본적으로 공유할 필요가 없기 때문에, 주로 자신의 로컬 저장소에서 관리한다.

새로운 기능 개발 및 버그 수정이 필요할 때 Develop 브랜치에서 분기된다.
개발이 완료되면 Develop 브랜치로 병합(merge) 한다.
더 이상 필요하지 않은 Feature 브랜치는 삭제한다.
새로운 기능에 대한 Feature 브랜치를 중앙 원격 저장소에 올린다. (push)

4. Release branch

이번 출시 버전을 준비하는 브랜치

어느정도 배포가 진행되고 배포할 수 있는 시점에 생성된다. (모든 기능이 정상인 상태 or 목표개발 기간종료 시점)
이후 테스트를 통해 최종 버그 수정(수정 후 Develop 브랜치에다가도 병합해줌)이라던가, 문서 추가등 실질적으로 Release 출시 하기 직전에 하는 단계들을 위한 브랜치이다.
모든 버그나 문서 수정이 완료 되면 Master 브랜치로 병합 및 버전 Tag를 부여하여 출시한다.
ex) release/1.2 (소프트웨어 버전 형식은 [Major].[Patch])