Git branch strategy, 깃 브랜치 관리 전략 공부

깃 브랜치를 정말 아무렇게나 사용하고 있었는데 최근 깃 강의를 듣고 브랜치를 규칙에 따라 사용해보면

협업에 수월함이 있지 않을까 싶어 정리해보고 사이드 프로젝트에 먼저 적용해 보려고 한다.

 

Git branch strategy

프로젝트 규모가 커지고 인원도 늘어나게 되면 하나의 레파지토리 내에 일정한 규칙이 존재해야 합니다.

저의 경우 소규모이지만 그래도 규칙은 필요한 것 같습니다 관리가 너무 어려워요ㅠ

오늘 공부한 깃 브랜치 관리 전략은 국내에서나 해외에서 통상적으로 사용하는 패턴이라고 합니다.

 

보통 Repository를 처음 만들고 나면 Branch 명은 Master로 생성이 됩니다.

(인프런 깃 강의를 들어보니 요즘은 master보다는 main으로 사용하길 권장한다고 합니다.)

저는 main을 master로 잡고 가겠습니다

 

main이 시작점이고

개발을 위해서는 별도의 develop 브랜치를 만들고 나아갑니다

 

main과 develop을 중심 줄기라고 생각하고 feature(기능), release(배포), hotfix(긴급수정)를 생성합니다.

 

• main
• develop
• feature / [Issue_number] of [feature_name] / [Short Description]
• release / [version_number]
• hotfix / [Issue_number] or Issue/[Issue_number]

 

main 브랜치

배포할 수 있는 브랜치

최종 배포 이력을 관리하기 위한 최상위 브랜치입니다

배포 가능한 상태만 관리한다고 합니다

 

develop 브랜치

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

main에서 분기되어 기능 개발을 위한 브랜치들을 병합하기 위해 사용

이 브랜치를 기반으로 개발을 진행.

모든 기능이 추가되고 버그가 수정되어 배포 가능한 안정적인 상태라면 main브랜치에 병합(merge)

 

feature 브랜치

기능을 개발하는 브랜치(로컬에서 사용)

feature 브랜치는 새로운 기능 개발 및 버그 수정이 필요할 때마다 'develop'브랜치로부터 분기합니다.

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

 

개발 완료시, 'develop' 브랜치로 병합하여 다른 사람들과 공유합니다.

(디벨롭 브랜치로 병합하여 그냥 푸시해도 되는 걸까? 피쳐를 로컬에서만 사용하니까 PR로는 안 하는 거 같은데 나중에 PR에 대해서도 자세히 공부해 보아야겠다)

1. 'develop'브랜치에서 새로운 기능에 대한 feature 브랜치를 분기
2. 새로운 기능에 대한 작업 수행
3. 작업이 끝나면 Local에서 개발한 Feature 브랜치를 develop에 병합
4. 필요를 다 한 feature브랜치는 삭제
5. 새로운 기능(feature에서 구현한 기능)에 대한 내용이 담긴 develop 브랜치를 main에 올린다(이 때는 PR 사용해야겠다)

 

release 브랜치

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

feature 브랜치에서 develop 브랜치로 어느정도 배포가 진행되고 배포할 수 있는 시점(모든 기능이 정상인 상태 or 목표 개발 기간 종료)일 때 release 브랜치를 생성한다. 그 이후 테스트를 통해 최종적으로 버그 수정이라든가, 문서 추가 등 실질적으로 release 출시 하기 직전에 하는 단계들을 위한 브랜치. 만약 버그가 있다면 수정하고 develop에도 병합

 

기능에 대한 병합 작업은 하지 않는 단계, 마지막 검토 단계. 기능에 대한 개발은 계속해서 develop이나 feature 브랜치에서 이어나감

 

모든 버그나 문서 수정이 완료되면 main브랜치에 병합 및 버전 Tag를 부여하여 출시한다.

또 배포를 준비하는 동안 release 브랜치가 변경되었을 수 있기 때문에 배포 후 develop에다가도 병합합니다.

 

태그는 release/1.2.1 이런식으로

관리 번호는 SemVer(Semantic Versioning), 버전의 형식은 [Major].[Minor].[Patch]

 

hotfix 브랜치

출시 버전에서 발생한 버그를 수정하는 브랜치

배포 후 갑작스럽게 수정해야하는 경우에 main에서 바로 수정하지 않고 hotfix브랜치로 분기한 후 버그를 수정하고 병합합니다.

에러나는 부분만 빠르게 수정할 때 사용합니다.

갑작스럽게 수정하는 부분이어야 하고 Patch 버전을(1.2.1)을 새롭게 변경합니다.

배포가 끝난 후 다시 develop에도 병합해줍니다.

 

 

 

 

참고한 블로그

https://www.inbogi.com/bok/2020/04/1/

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