230612 TIL

Git Flow

 

스터디원과 이야기 나누던 중, 면접에서도 받은 질문 중 하나가 "브랜치 관리 어떻게 하시나요?"에 대한 질문이었어서

브랜치를 어떻게 나누는 것이 좋은지 어떤 전략이 있는지?에 대한 이야기를 나누다가 Git Flow에 관해서 찾아보시라고 알려주셔서 이참에 알아보게 되었다.

이걸 보니까 내가 참 브랜치를 개판으로 관리하고 있었음을 깨달았다 ... ㅋㅋㅋㅋ 이제부터라도 브랜치 정리를 좀 하고 진행해야겠다.

 

참고 레퍼런스

https://overcome-the-limits.tistory.com/7

[협업] 협업을 위한 Git Flow 설정하기

 

- main/master 브랜치: 배포하는 버전만 있는 브랜치

릴리즈 버전을 태그를 활용하여 표시한다. 

 

https://velog.io/@jhyeom1545/Git-Github-tag%EB%8B%A4%EB%A3%A8%EA%B8%B0-realease.

[Git, Github] tag다루기, release

 

- develop 브랜치: 그 다음 기능을 개발할 브랜치. 개발할 때 생기는 다른 브랜치들이 모두 여기서부터 시작된다고 보면 됨

develop 브랜치는 배포되어 있는 앱에서 변경점이 있는 부분을 개발하는 브랜치니까 main/master로부터 생성

- feature 브랜치: develop 브랜치로부터 갈라져나오는 브랜치고, 기능 별로 분리하여 각각을 보존하는 역할

feautre/기능번호, feature/기능이름, feature/이슈번호 등으로 네이밍

(예를들어 로그인이면 feature/login)

여기서 하나의 기능이 개발 완료되면 develop 브랜치로 머지됨

=> 팀원과 협업할 때 이렇게 feature 별로 나누어서 각자 소스코드를 관리하면 될것 같다.

- release 브랜치: 배포를 위해 준비하는 브랜치로, 배포하기 전 (main/master 브랜치에 합치기 전) 에 최종적으로 검토하고 버그를 수정하기 위한 브랜치이다. develop 브랜치에서 생성되며, 여기서 발견된 버그를 수정하게 되면 develop 브랜치에도 반드시 머지를 해주어야함!

release/v1.0.1 이런식으로 네이밍

- hotfix 브랜치: 배포한 버전에서 우선적으로 수정되어야 하는 사항을 수정하는 브랜치로, master와 develop 브랜치 모두 머지한다. (hotfix를 따로 만드는 이유는 다른 팀원도 develop 브랜치에서 개발하고 있을 수 있으니!)

hotfix/v1.0.1 이런식으로 네이밍

 

❓ 그러면 여기서 들었던 의문은 이렇게 되면 브랜치가 너무 많아지지 않나? 삭제하는 시점이 있나? 해서 찾아봤다.

 

feature 브랜치의 경우 기능이 온전히 완성이 되고 해당 기능의 결과가 좋지 못하여 버리게 되면 해당 기능 브랜치를 지우게 되고

hotfix 브랜치는 버그 픽스를 위한 브랜치이기 때문에, 버그가 픽스되고 develop과 master 모두 머지한 후에 바로 지우게 된다.