Git Branch Naming & Strategy

평소대로 기능 개발을 위해 gitlab에서 브랜치를 만들려던 찰나!

브랜치도 명명 규칙이 있을 것 같아서 갓글에 검색.

알고 보니 네이밍 규칙뿐만 아니라 브랜치 전략이란 게 있었음.

오전 시간을 갈아 넣어 속성으로 공부한 바탕으로 정리해봄.(자세한 설명은 참조사이트 참고. / 엄청 잘 정리되어있음.)

 

※ Git 브랜치 전략
- 브랜치 전략이란 여러 개발자가 하나의 저장소를 사용하는 환경에서 저장소를 효과적으로 활용하기 위한 work-flow.
- 브랜치의 생성, 삭제, 병합 등 git의 유연한 구조를 활용해서, 각 개발자들의 혼란을 최대한 줄이며 다양한 방식으로 소스를 관리하는 역할을 함. 

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

- 가장 널리 사용되는 2가지 브랜치 전략이 있음.
    1. git-flow 전략
    2. github-flow 전략

 

1. Git-flow 전략
- 1개월 이상 긴 호흡으로 개발하여 주기적으로 배포, Q&A 및 테스트, hotfix 등 수행할 수 있는 여력이 있는 팀이라면 적합
- 규모가 큰 회사에서 사용하는 느낌(주관적 피셜)

1-1. Branch 종류
- Main branch  :  중앙 저장소에는 수명이 무한한 두 가지 메인 브랜치가 있음.
① master branch(제품으로 출시될 수 있는 브랜치)
- 사용자에게 배포 가능한 상태만 관리.
- 배포 이력을 관리하기 위해 사용.

② develop branch(다음 출시 버전을 개발하는 브랜치)
- 기능 개발을 위한 브랜치들을 병합하기 위해 사용.
- 모든 기능이 추가되고, 버그가 수정되어 배포 가능한 상태일 때 master 브랜치에 merge(병합)함.
- 평소에는 이 브랜치 기반으로 개발 진행.

- Supporting branches : 제한된 수명을 갖는 브랜치.
① feature branch(기능을 개발하는 브랜치)
- 새로운 기능 개발 및 버그 수정이 필요할 때마다 develop branch에서 분기.
- 작업은 기본적으로 공유할 필요가 없어서 로컬에서 관리.
- 개발이 완료되면 develop 브랜치로 merge(병합)하여 다른 사람들과 공유 및 테스트.

② release(출시 버전을 준비하는 브랜치)
- 배포를 위한 전용 브랜치로써 최종적인 버그 수정, 문서 추가 등 배포와 직접적을 관련된 작업 수행.
- 이외의 작업들은 release 브랜치에 추가하지 않음.

③ hotfix(출시 버전에서 발생한 버그를 수정하는 브랜치)
- 버그 수정을 위한 브랜치.
- 배포한 버전에 급하게 수정할 필요가 있을 경우, master 브랜치에서 분기하는 브랜치.
- 변경 사항은 develop 브랜치에도 merge(병합).

 

git branch 전략

 

2. Github-flow 전략
- 수시로 릴리즈 되어야 할 필요가 있는 서비스를 지속적으로 테스트하고 배포하는 팀에게 적합.
- 팀 단위가 작은 팀이거나 기능 수정사항이 많을 때 사용하는 느낌(주관적 피셜)

2.1 github-flow 흐름
① 브랜치 생성
- master 브랜치에서 새로운 브랜치를 만듦.
- 체계적인 분류 없이 브랜치 하나에 의존하기 때문에 이름을 의도에 맞게 작성해야 함.

② 개발 중 커밋 & 푸쉬
- 커밋 메세지를 자세하고 명확하게 작성.
- 원격 브랜치로 수시로 push 하기 /  다른 사람들도 확인할 수 있고, 하드웨어에 문제가 발생했을 때를 대비.

③ Pull Request 생성
- 코드 리뷰, 피드백이 필요할 때 생성.
- merge 준비가 완료되었을 때 생성 > master 브랜치로 반영을 요구.

④ 리뷰 & 토의
- Pull Reqeust가 master 브랜치와 merge(병합)하기 전 충분한 토의와 테스트가 필요.

⑤ 테스트
- 리뷰와 토의가 끝났다면 해당 브랜치를 라이브 서버(혹은 테스트 환경)에 배포.
- 배포 시 문제가 발생한다면 전 master 브랜치를 다시 배포하여 초기화함.

⑥ 최종 Merge
- 라이브 서버(혹은 테스트 환경)에 배포했음에도 문제가 발생하지 않는다면 master 브랜치에 push 후 즉시 배포.
- master 브랜츠로 merge(병합)되고 push까지 진행했을 때에는 즉시 배포되어야 함.

 

여기까지 대체적인 Git branch 전략에 대해서 공부해봄.

 

사실 브랜치 명명규칙을 알려고 검색했는데 다른 개념 공부도 공부해버림.

 

다시 돌아와서 브랜치 명명 규칙은 간단하게 정리함.

 

※ 브랜치 네이밍 규칙
① master branch, develop branch 
- 본래 이름 그대로 사용하는 경우가 일반적.

② feature branch
- 자유롭게 가능한데 master, develop 중복은 사용하지 않고, feature/기능요약 형식을 추천한다고 함.
ex) 로그인 기능 개발 시 : feature/login
- 이슈 추적을 사용한다면 feature/{issue-number} - {feature-name} 같은 형식.
ex) feature/1-init-project 등..

③ release branch
- release-... or release/... 같은 이름이 일반적.
ex) release-1.2 등...

④ hotfix branch
- hotfix-... 같은 이름이 일반적.
ex) hotfix-1.3.2 등...

 

사실 제가 하는 프로젝트는 한두명이서 진행하기 때문에 git-flow 전략은 맞지 않다고 생각함.

유지보수라서 자잘한 기능개발이 많기 때문에 github-flow 전략이 맞다고 판단함.

앞으로 브랜치를 생성하면 feature/... 식으로 할려는 습관을 만들어야겠음.

오늘 공부 끝. 날이 쌀쌀해지는데 다들 감기 조심하시고 행복한 하루 되길.😉

 

 

📢참조

 

https://velog.io/@kim-jaemin420/Git-branch-naming

 

Git branch & naming

 

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#thankYou

 

[GIT] 📈 깃 브랜치 전략 정리 - Github Flow / Git Flow