git flow 전략이란?

 

 

 

klub 개발 프로세스

klub 팀에서 이번주에 1.2.0 버전을 배포 예정이라서 QA를 진행중이어서 git flow 전략에 조금 더 자세히 알아보고자 글을 작성하였습니다. 

 

 

 

git 브랜치 전략이란?

브랜치 전략이란 여러 개발자가 하나의 저장소를 사용하는 환경에서 효과적으로 협업을 하기 위한 전략입니다.

 

브랜치 생성, 삭제, 병합 등 git flow 전략을 사용하여 개발자들이 소스를 편하게 관리할 수 있습니다.

 

git 브랜치 전략에는 git flow 전략뿐만 아니라 github-flow 라는 전략도 있지만 klub 팀에서는 git flow 전략을 사용하기에 git flow에 대해서 조금 더 자세히 알아볼 예정입니다.

 

만약 git flow가 없다면 개발자들은 어떤 브랜치에 PR을 날려야 할지 어떤 브랜치부터 시작하여 개발을 시작해야 할지 배포를 할 때 개발 브랜치와 실제 배포 브랜치를 어떻게 관리할지 혼란이 생기기 때문에 git flow 전략을 통해서 일종의 협업 프로세스를 약속을 하고 개발자들이 협업을 할 수 있습니다.

 

 

---

Git-Flow 브랜치 구조

 

master : 라이브 서버에 제품으로 출시되는 브랜치.

develop : 다음 출시 버전을 대비하여 개발하는 브랜치.

feature : 추가 기능 개발 브랜치. develop 브랜치에 들어간다.

release : 다음 버전 출시를 준비하는 브랜치. develop 브랜치를 release 브랜치로 옮긴 후 QA, 테스트를 진행하고 master 브랜치로 합친다.

hotfix : master 브랜치에서 발생한 버그를 수정하는 브랜치.

 

 

 

 

 

---

메인 브랜치

메인 브랜치는 master 브랜치와 develop 브랜치 두 종류를 말한다.

 

master 브랜치는 배포 가능한 상태만을 관리하는 브랜치를 말하며,

develop브랜치는 다음에 배포할 것을 개발하는 브랜치이다.

즉 develop 브랜치는 통합 브랜치의 역할을 하며, 평소에는 이 브랜치를 기반으로 개발을 진행한다.

 

 

 

 

---

릴리즈 브랜치(release branch)

릴리즈 브랜치는 배포를 위한 최종적인 버그 수정 등의 개발을 수행하는 브랜치를 말한다.  

 

release 브랜치란 새로운 제품을 배포하고자 할 때 사용하는 가지이다.

 

develop 브랜치에 버전에 포함되는 기능이 merge 되었다면 QA를 위해 develop 브랜치에서부터 release 브랜치를 생성한다. 

배포 가능한 상태가 되면 master 브랜치로 병합시키고, 출시된 master 브랜치에 버전 태그(ex, v1.2.0)를 추가한다.

release 브랜치에서 기능을 점검하며 발견한 버그 수정 사항은 develop 브랜치에도 적용해줘야 한다.

그러므로 배포 완료 후 develop 브랜치에 대해서도 merge 작업을 수행해야 한다. 

 

 

 

---

핫픽스 브랜치(hotfix branch)

핫픽스 브랜치는 배포한 버전에서 긴급하게 수정할 필요가 있을 때 master 브랜치에서 분리하는 브랜치를 말한다.  

 

hotfix 브랜치란 제품에서 버그가 발생했을 경우에는 처리를 위해 이 가지로 해당 정보들을 모아준다. 버그에 대한 수정이 완료된 후에는 develop, master에 곧장 반영해주며 tag를 통해 관련 정보를 기록해둔다.

 

버그를 잡는 사람이 일하는 동안에도 다른 사람들은 develop 브랜치에서 하던 일을 계속할 수 있다.

이 때 만든 hotfix 브랜치에서의 변경 사항은 develop 브랜치에도 merge 하여 문제가 되는 부분을 처리해줘야 한다.

release 가지가 생성되어 관리되고 있는 상태라면 해당 가지에 hotfix정보를 병합시켜 다음번 배포 시 반영이 정상적으로 이루어질 수 있도록 해준다.

Hotfix는 보통 다급하게 버그를 고치기 위해 생성되는 가지이기 때문에 버그를 해결하면 보통 제거하는 일회성 가지다.

 

 

 

 

 

---

 

요약

 

5가지 브랜치 중에 가장 많이 사용하는 브랜치는 develop 브랜치이다. 보통 개발자들이 개발을 할 때 develop 브랜치를 git pull 한다음 개발을 시작한다. master 브랜치는 develop 브랜치에서 release-1.2.0과 같이 버전에 맞는 릴리스 브랜치를 만들고 브랜치 QA를 통해 오류가 없는지 검증 후 master 브랜치와 develop 브랜치에 병합한다. 따라서 배포 후 master 브랜치와 develop 브랜치는 똑같은 내용의 코드를 담고 있다.

 

master 브랜치와 develop 브랜치 외에 hotfix 브랜치와 feature 브랜치가 남았는데 hotfix 브랜치는 배포 후에도 문제가 발생할 경우 빨리 오류를 수정하고 바로 master 브랜치와 develop 브랜치에 병합하고 이후 사용되지 않는다. feature 브랜치는 master 브랜치에는 병합을 하지 않고 develop 브랜치에서 개발 중일 때 아래 그림과 같이 추가하는 기능마다 feature 브랜치를 만들고 각자 코드를 짜고 PR을 날리면 깃허브 페이지에 Pull requests에 등록되는데 여기서 코드리뷰를 통해 시니어 개발자 및 동료 개발자들이 승인을 하면 develop 브랜치에 머지를 하면 개발 서버에 변경사항이 적용된다.

 

 

 

 

 

 

 

위 그림처럼 현재 1.2.0 릴리즈 브랜치에서 QA를 진행중이며 QA가 완료되면 main 브랜치에 머지하여 배포가 된다. klub 프로젝트를 진행하면서 협업 프로세스를 처음 경험하고 공부하면서 많은 것들을 배우고 있다. 언어가 달라서 조금 낯선 부분도 있지만 코드 영역 외에 DB나 협업 쪽에서 많은 것들을 배우고 특히 프론트와 상호작용하면서 개발을 할 때 백엔드 쪽을 먼저 개발해야 할 경우 postman으로 api 통신을 해야 하는데 이런 것들이 처음에는 어색해서 오래 걸렸지만 이제 조금씩 적응해서 다행인 것 같다.

 

각자 feature 브랜치를 파서 개발을 하면서 느낀 점은 작업 영역이 겹칠 때 소통이 굉장히 중요한 것 같다. 앞으로는 다른 사람들의 작업 영역을 먼저 파악하고 개발을 시작해야 더 효율적으로 할 수 있지 않을까 느꼈고 처음에 RESTful api 설계 가이드나 DB의 구조 등을 더 꼼꼼하게 작성해야 나중에 덜 힘들다는 것을 느꼈다.