Git 브랜치 전략을 알기전 그냥 현업에서 시키는 대로 무작정 따라했다.그 이후로 면접에서 질문을 받았을때도 솔직히 대답을 잘하지 못했고 그냥 해왔던 방법을 설명한것 같았다. 이번 기회에 깃 브랜치 전략에 대해 다시 공부해봤다.
브랜치 전략은 크게 Git flow, GitLab flow, Github flow 3개로 보통 사용하고 있다. 여기서는 주로 사용되는 Git flow와, Github flow에 대해서만 다룰 예정이다.
브랜치를 왜 사용 할까
그냥 간단히 생각하면 쉬운것 같다. 협업으로 팀끼리 일을하는데 같은 도화지에 그림을 다같이 그리기 시작하면 꼬이기 쉽상이다. 도화지에 각자 맡은 그림을 병렬적으로 나눈뒤(브랜치) 작업이 끝나고 합치는것과 같다. 합치는 과정에서 진행상황을 알수도 있고 서로에 대한 의견도 나눌수 있다. 그렇게 함으로써 더 좋은 그림(코드) 를 그릴수도있고 의견도 조율할 수 있는 장점이 있다
Git Flow
Git Flow는 크게 Main 브랜치, Develop 브랜치, Supporting 브랜치로 구분하여 브랜치를 관리한다. 이때, Supporting 브랜치는 또 다시 Feature 브랜치, Release 브랜치, Hotfix 브랜치로 나뉜다.
Main 브랜치와, Develop 브랜치는 개발 프로세스 전반에 걸쳐 항상 유지되는 브랜치이다. 반면, Supporting 브랜치는 필요할 때마다 생성되고, 역할을 다하면 삭제된다. Supporting 브랜치 덕분에 팀이 병렬적으로 업무를 할 수 있게된다.
Main 브랜치
Main 브랜치는 출시 가능한 프로덕션 코드를 모아두는 브랜치이다. Main 브랜치는 프로젝트 시작 시 생성되며, 개발 프로세스 전반에 걸쳐 유지된다. 배포된 각 버전을 Tag를 이용해 표시해둔다.
Develop 브랜치
다음 버전 개발을 위한 코드를 모아두는 브랜치이다. 개발이 완료되면, Main 브랜치로 머지된다.
Feature 브랜치
하나의 기능을 개발하기 위한 브랜치이다. Develop 브랜치에서 생성하며, 기능이 개발 완료되면 다시 Develop 브랜치로 머지된다. 머지할때 주의점은 Fast-Forward로 머지하지 않고, Merge Commit을 생성하며 머지를 해주어야 한다. 이렇게해야 히스토리가 특정 기능 단위로 묶이게 된다.
Release 브랜치
소프트웨어 배포를 준비하기 위한 브랜치이다. Develop 브랜치에서 생성하며, 버전 이름 등의 소소한 데이터를 수정하거나 배포전 사소한 버그를 수정하기 위해 사용된다. 배포 준비가 완료되었다면 Main과 Develop 브랜치에 둘다 머지한다. 이때, Main 브랜치에는 태그를 이용하여 버전을 표시한다.
Release 브랜치를 따로 운용함으로써, 배포 업무와 관련없는 팀원들은 병렬적으로 Feature 브랜치에서 이어서 기능을 개발할 수 있게된다.
->네이밍은 release/v1.1 과 같은 형태로 생성한다.
Hotfix 브랜치
이미 배포된 버전에 문제가 발생했다면, Hotfix 브랜치를 사용하여 문제를 해결한다. Main 브랜치에서 생성하며, 문제 해결이 완료되면 Main과 Develop 브랜치에 둘다 머지한다.
Release 브랜치와 마찬가지로 Hotfix 브랜치를 따로 운용함으로써, 핫픽스 업무와 관련없는 팀은 병렬적으로 기능 개발을 할 수 있다.
Github Flow
Topic 브랜치
새로운 기능을 개발할 때에는 Topic 브랜치를 Main 브랜치로부터 생성한다. Git Flow의 Feature 브랜치와 동일한 역할을 한다. 또한 별도로 Hotfix 브랜치를 관리하지 않으며, 버그 수정도 Topic 브랜치에서 진행한다.
이때, Topic 브랜치의 이름은 기능을 설명하는 명확한 이름으로 네이밍 해야한다. 예를 들면, user-content-cache-key, submodules-init-task, redis2-transition 등이 있다.
Topic 브랜치의 커밋은 기능이 완성되지 않았더라도 꾸준히 Push 한다. 노트북 분실, 작업 컴퓨터의 고장등의 위험으로 코드가 유실되는 것을 막아준다. 이것보다 더 중요한 이유는 꾸준히 Push 함으로써 구성원 모두가 끊임없이 커뮤니케이션 할 수 있게 해준다.
=> 기계적으로 git flow 방식으로 프로젝트를 해왔다. 각각 브랜치들의 특징을 하나하나 파헤쳐보니 왜 이러한 방식들이 사용됐는지 알게 됐고 이 방법 말고 다양한 방법이 또 존재한다는 사실을 알게 됐다.
참고
