[Git] branch 종류 및 naming 참고 및 주의사항

Branch 종류

1. master branch

제품으로 출시될 수 있는 브랜치

 

2. develop branch

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

- 기능 개발을 위한 브랜치들을 병합하기 위해 사용한다.

즉, 모든 기능이 추가되고 버그가 수정되어 배포 가능한 안정적인 사태라면 develop 브랜치를 master 브랜치에 merge(병합)한다.

평소에는 이 브랜치를 기반으로 개발을 진행한다.

 

3. Supporting branches 

평소에 자주 사용하는 브랜치로 팀 구성원 간에 평행 개발을 하게 하고 기능을 쉽게 추적할 수 있다.

이 supporting 브랜치들은 메인 브랜치와는 달리 결국 제거될 것이므로 항상 제한된 수명을 갖는다.

 

세 가지 supporting 브랜치

1) feature branch

기능을 개발하는 브랜치

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

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

 

개발이 완료되면 develop 브랜치로 merge하여 다른 사람들과 공유한다.

1. develop 브랜치에서 새로운 기능에 대한 feature 랜치를 분기한다.
2. 새로운 기능에 대한 작업을 수행한다.
3. 작업이 끝나면 develop 브랜치로 merge한다.
4. 더 이상 필요하지 않은 feature 브랜치는 삭제한다. - 많은 줄기 ( branch)는 작업에 혼란을 줄 수 있다.
5. 새로운 기능에 대한 feature 브랜치를 중앙 원격 저장소에 올린다.
   1. 그러면 feature 브랜치는 로컬에서만 관리하고 추가한 기능이 담긴 feature 브랜치를 develop 원격 저장소에 올리는 건가??? 그럼 develop 브랜치는 로컬에 생성할 필요가 없다?
   2. develop 브랜치에서 feature branch를 로컬에 생성하는 방법
      1. git checkout -b feature/{function} {develop Branch}

2) release branch

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

배포를 위한 전용 브랜치로 한 팀이 해당 배포를 준비하는 동안 다른 팀은 다음 배포를 위한 기능을 개발할 수 있다.

1팀은 1.2버전을 개발하고 2팀은 1.3버전을 개발한다.

release 브랜치는 배포를 위한 최종적인 버그 수정, 문서 추가 등 배포와 직접적으로 관련된 작업을 수행한다.

이러한 작업들 이외에 release 브랜치에 새로운 기능을 추가로 merge하지 않는다.

 

3) hotfix branch

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

배포한 버전에 긴급하게 수정을 해야 할 필요가 있을 경우, master 브랜치엣 ㅓ분기하는 브랜치이다. develop 브랜치에서 문제가 되는 부분을 수정하여 배포 가능한 버전을 만들기에는 시간도 많이 소요되고 안정성을 보장하기도 어려우므로 바로 배포가 가능한 master 브랜치에서 직접 브랜치를 만들어 필요한 부분만 수정한 후 다시 master 브랜치에 병합하여 이를 배포한다.

1. 배포한 버전에 긴급하게 수정할 부분 발생 -> master 브랜치에서 hotfix 브랜치 분기
2. 문제가 되는 부분 수정 후 master 브랜치에 merge하고 배포
3. hotfix 브랜치에서의 변경 사항은 develop브랜치에도 merge한다.

버그 수정만을 위한 Hotfix 브랜치를 따로 만들었기 때문에 다음 배포를 위해 개발하던 작업 내용에 전혀 영향을 주지 않는다. hotfix는 master 브랜치에서 분리한 임시 브랜치이다.

- 근데 이런 branch를 따는건 원격 저장소에서 말하는건가~?

 

 

Branch 네이밍 규칙

1) master branch, develop branch

master와 develop 브랜치는 본래 이름 그대로 사용하는 경우가 일반적!

 

2) feature branch

어떤 이름도 가능하지만 master, develop, release-..., hotfix-...와 같이 다른 브랜치 명으로 사용하고 있는 것들은 사용할 수 없다.

feature/기능요약 형식을 추천한다고 한다. ex) feature/login

feature/{issue-number}-{feature-name} 이슈추적을 사용한다면 이와 같은 형식을 따른다.

ex) feature/1-init-project, feature/2-build-gradle-script-write

 

3) release branch

release-RB_... 또는 release-... 또는 release/... 같은 이름이 일반적이라고 한다.

release-... 형식을 추천한다고 한다. ex) release-1.2 -> 근데 feature을 /로 할거면 release로 /로 하는게 혼선이 덜오지 않나?

 

4) hotfix branch

hotfix-... 형식을 추천한다고 한다. ex)hotfix-1.2.1

 

우리 팀에 적용하게 되면

master : 바로 배포해서 사용 가능한 브랜치 -> merge 시 merge request 요청을 받아야 한다. ( 이부분은 팀에서 매번 어떻게 하냐,귀찮다고 하는데 어떻게..?)

develop : 그럼 이 부분을 request없이 merge하는 형태로 가면 되는것 같다.

feature : 기능별 이름 naming 규칙 : feature/login

hotfix : 배포해서 고객사에 적용된 master 브랜치에 문제가 있을 경우 hotfix 브랜치를 따서 오류만 수정하고 master이랑 develop 브랜치에 merge한다.

 

동일한 내용이지만, 실제 적용하기까지 어려움이 있을 것 같다. 제일 직급이 낮기도 하고 SVN만 사용하던 팀이고 모든 프레임워크가 새롭기 때문에, 공부할게 많고 일정도 타이트한데..걱정이지만, 이것을 기반으로 정보를 쌓고, 체계를 잡아보자.

 

 

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

Git branch & naming

 

git 작업하면서 느낀 문제점과 피드백

main에서 작업 브랜치로 머지받는건 말이 안된다.

 

무작정 작업하기 전에 git flow에 대해 학습하고 전략을 수립하자.

 

기본적인 루틴 

1. main에서 기능별 브랜치따기

2. 기능별 브랜치 작업

3. 작업 완료 후 main에 pr

 

dev가 있다면 dev에 테스트 완료된 것을 넣고 main은 release가 완료도니 것만 넣는게 더 편하지 않을까?

 

main으로 넘어가는 시점이 dev에서 동작 확인하고 정상 동작하면 main에 머지하는 형태라면 브랜치 싸이클이 꼬이기 너무 쉽다.

- main -> feature -> dev -> main ( 2021.12.09일 기준) <- 여기서 dev가 있을 이유가 없다 현재는

- dev -> feature -> dev -> main

으로 수정하면 어떨까?

통합 테스트는 그냥 작업 브랜치에서 dev 땡겨와서 작업 브랜치에서 할 수도 있다.

 

피드백 예시 1

dev -> feature1, feature2 ->

1) feature1 작업 완료 -> dev PR -> 배포 준비 완료

2) feature2 작업 완료-> dev pull -> dev PR -> 배포 준비 완료

 

피드백 예시 2

master -> develop
작업 시작 시 develop -> feature/기능명
작업 완료 시 feature -> test
테스트 완료 시 develop에 feature 병합
상용 배포 시 develop -> release
배포 완료 시 develop에 release 병합, master에 develop 병합 후 release 버전 태그