최근 누군가 회사에서 사용하는 git 브랜치 전략이 무엇이냐고 물어본 일이 있었다. 아니 git에도 방법론이 따로 있나🤔🤔🤔..? 당당하게 그런거 없다라고 말하고서는 집에 와서 허겁지겁 찾아보니 내가 매일 사용하던 브랜치 관리 방식이 git-flow라는 이름을 갖고 있었다. 아는 만큼 보인다고..😨 부끄러웠던 내 자신을 뒤로하고 오늘은 이 git-flow가 어떤 방식으로 브랜치를 관리하는지 알아보고자 한다.
📌 Git-flow의 특징
Git-flow는 5가지의 브랜치를 가진다.
- master
- develop(dev)
- feature
- release
- hotfix
이 브랜치는 항상 존재하는 브랜치와 특정 기간만 존재하는 보조 브랜치로 나뉘게 된다.
| 고정 | 임시 |
|---|---|
| master | feature |
| develop | release |
| hotfix |
일부 브랜치를 고정으로 두는 이유는 여러 브랜치의 커밋들을 병합해 개발한 내용이 요구사항에 맞게 동작하는지 실제로 사용 또는 테스트 해보기 위함 때문인데, 보통 develop는 테스트를, master는 테스트가 끝난 기능들을 제품으로 묶어 운영하기 위한 용도로 사용한다. 이 둘의 특징은 각자의 용도를 위해 필요한 임시 또는 상시 서버를 가지고 있다는 것이며 master브랜치에서 새로운 제품이 출시되면 develop 브랜치는 master 브랜치를 기준으로 초기화되어 다음 제품 출시 전까지 새로운 커밋들을 추가하게 된다.
master(main) : 현재 릴리즈 버전(운영)의 브랜치. 프로덕션 중인 코드와 일치해야 한다.
develop : 새로운 기능을 개발/테스트하는 브랜치.
feature, release, hotfix 브랜치는 처음 생성될때부터 각자 특정한 목적을 갖고 있으며 이 목적을 달성할 경우 해당 브랜치는 소멸되는 특징을 갖는다.
feature : 주어진 요구사항에 대한 기능을 개발하는 브랜치
release : 해당 버전의 출시를 위한 브랜치
hotfix : 운영상에 생긴 버그를 수정하는 브랜치
이 5가지의 브랜치의 흐름은 대략 이렇다.
1. 새로운 버전이 릴리즈되면 develop(dev)브랜치는 master 브랜치로 초기화시키고 작업 중이던 브랜치(feature)는 master를 기준으로 rebase된다(프로젝트가 처음 생성되는 경우 master/main 브랜치만 존재한다).
2. 새로 생성되는 기능들에 대한 브랜치는 jira 티켓을 통해 master를 기준으로 생성되도록 한다(ex. feature/ticket-1).
3. feature 브랜치에 요구사항에 대한 작업이 완료되면 develop 브랜치에 해당 내용의 커밋들을 병합(merge)한다. 팀에 따라 병합하기 전 PR(Pull Request)이 생성되어 검토하는 과정을 거친 뒤 병합을 진행할수도 있다.
4. 배포 사항에 대한 테스트가 완료되면 develop 브랜치를 기준으로한 release 브랜치가 생성된다. 생성된 브랜치는 운영 배포 전까지 QA 팀에 의해 테스트를 진행하며 개발자는 다음 릴리즈 버전의 기능들을 develop 브랜치에서 작업할 수 있다.
5. 릴리즈 과정에서 발생하는 문제들은 develop 브랜치에서 수정을 진행하고, 완료되면 릴리즈 버전의 태그와 함께 master로 병합을 진행한다.
6. 배포 후 운영 상 문제가 생길 경우 hotfix 브랜치가 생성되고 크리티컬한 정도에 따라 해당 내용은 다음 릴리즈 버전에 적용될수도, 당장 배포될수도 있다.
📌 Git-flow의 장점
👉🏻 Git-flow 전략을 사용하게 될 경우 다음과 같은 장점을 가질수 있다.
⭐️ 1. 여러 릴리즈 버전에 대한 작업이 가능하다.
릴리즈 버전에 맞게 feature 브랜치를 지속적으로 통합 관리하기 때문에 버전 환경에 맞게 기능에 대한 작업이 가능하다.
⭐️ 2. 릴리즈 버전에 대한 추적이 쉽다.
각 버전에 대한 테스트가 개별적으로 이루어지기 때문에 문제 발생시 해당 이슈에 대한 버전 추적이 비교적 편리하다.
⭐️ 3. 동시 작업이 가능하다.
브랜치가 기능 별로 각각 생성되기에 원격저장소만 신경 쓴다면 여러 개발자가 한 브랜치에서 한가지 기능에 대한 작업이 가능하다.
👉🏻 내가 느낀 장점
⭐️ 1. 유지보수가 편리하다.
해당 작업에 대한 내용이 티켓으로 관리되고 배포 후에도 기록이 남아 있기에 이슈에 대한 담당자 및 코드 추적이 용이하다.
⭐️ 2. 브랜치의 버전 관리가 쉽다.
메인 브랜치와의 싱크를 계속해서 맞추기 때문에 운영 버전과 작업한 코드에 대한 비교가 한 눈에 들어온다. 코드 리뷰하기 용이하다.
이처럼 Git-flow 전략은 개발 주기가 운영 버전을 중심으로 브랜치가 관리되기 때문에 실시간 이슈에 대한 대응이 필요한 유지보수 프로젝트에 적합하다고 생각한다.
📌 우리 회사에서는...
직전 프로젝트에서 역시 운영을 기반으로 한 workflow를 가지고 있었기 때문에 이에 적합한 Git-flow 전략이 사용되었다. 사용 과정에서 협업의 편의를 위해 정해둔 룰들이 몇가지 있다.
1. PR 직전 커밋 로그는 티켓당(feature) 하나로 한다.
동료 검토시 소스코드를 편하게 비교 분석하기 위해 PR 전 작업한 커밋 로그들을 하나로 squash 한다. 또한 커밋 로그는 알아보기 쉽도록 티켓 번호와 요구사항 내용을 명확하게 작성한다.
2. develop 브랜치에서는 작업하지 않는다.
develop 브랜치는 테스트를 위한 브랜치이기도 하다. 때문에 추후 릴리즈될 환경과의 싱크를 맞추기 위해 이 브랜치에는 병합만 가능하다.
3. 병합 과정에서 나는 충돌은 되도록 사전에 방지한다.
예컨대 다음 릴리즈 버전에 여러 브랜치에서 같은 파일을 수정하는 경우 나중에 병합할 경우 반드시 충돌이 일어날수 밖에 없다. 때문에 같은 파일의 어느 부분이 수정되었는지 먼저 논의한 뒤 이에 대한 해결 방향성을 모색한다(물론 같은 파일에 대한 수정은 되도록 피하는게 좋다).
마치며...
Git-flow 말고도 git은 여러 다양한 전략들이 존재한다. 현재 사용 중인 이 프로젝트에 대한 Git-flow의 적합성을 판단하기 위해서는 타 전략들에 대한 분석과 비교가 이뤄져야 한다. 그렇기에 다음 시간에는 어떤 Git 전략들이 있는지 알아보는 시간을 갖고자 한다.
나만의 성장 일기