[Git] Git 브랜치 전략 (with. 스타카토)

목차

• Intro
• Git 브랜치 전략이란?
• Git 브랜치 전략 종류
  • GitHub Flow
  • Git Flow
• 스타카토의 Git 브랜치 전략
• Outro

Intro

스타카토는 그동안 배포할 때마다 Git 충돌로 굉~~~장히 많은 고생을 했다. 수많은 시행착오를 거친 끝에 이제는 Git 브랜치 전략이 어느 정도 자리를 잡은 것 같다. 그렇게 느낀 이유는 최근 진행한 v1.4.0 배포가 지금까지 중에 가장 빠르게 끝났기 때문이다!

그래서 오늘은 Git 브랜치 전략에 관해 이야기해 보려고 한다.

Git 브랜치 전략이란?

브랜치(branch)의 사전적 의미는 다음과 같다.

branch
1. Noun 나뭇가지
2. Noun 지사, 분점
3. Verb (둘 이상으로) 갈라지다[나뉘다]

브랜치는 원래 나뭇가지라는 뜻을 가지고 있다. Git 브랜치 전략도 이 '나뭇가지'라는 의미를 떠올리면 훨씬 이해하기 쉽다. 줄기에서 가지가 뻗어나가듯 하나의 main 브랜치에서 여러 브랜치가 갈라져 나와 각자의 역할을 한다.

즉, Git 브랜치 전략이란 여러 개발자가 하나의 저장소를 사용하는 환경에서 저장소를 효과적으로 활용하기 위한 work flow다.

Git 브랜치 전략 종류

가장 보편적인 브랜치 전략으로는 GitHub Flow, Git Flow 두 가지를 꼽을 수 있다. GitHub Flow와 Git Flow에 대해 알아보자.

GitHub Flow

GitHub Flow란 GitHub에서 제안하는 Git 브랜치 전략이다.

GitHub flow is a lightweight, branch-based workflow. The GitHub flow is useful for everyone, not just developers.

GitHub은 GitHub Flow를 개발자뿐만 아니라 모든 사람에게 유용한 가벼운 브랜치 기반 work flow라고 소개한다. GitHub Flow는 크게 6가지 절차로 나눠 진행된다.

1. 브랜치를 생성하여 작업을 분리
2. 변경 사항을 커밋하고 푸시
3. Pull Request를 생성하여 리뷰 요청
4. 리뷰를 반영하여 수정
5. Pull Request를 병합하여 변경 사항을 적용
6. 작업이 완료되면 브랜치를 삭제

GitHub Flow는 빠른 개발과 배포를 지원하는 방법으로 널리 사용된다. 하지만 명확히 분리된 release branch가 필요한 서비스에서는 적합하지 않다.

Git Flow

명확하게 분리된 release 브랜치가 필요한 서비스에서는 Git Flow 전략을 활용할 수 있다.

Git Flow는 GitHub Flow에 비해 복잡하므로 이를 나무에 비유하여 설명하겠다. 나무는 크게 보면 줄기와 가지로 이루어져 있다. main 브랜치는 나무에서 가지를 치고 잎이 돋아나게 하는 나무줄기와 같다. 항상 건강하고 곧게 뻗어 있어야 하고, 여기서 모든 가지가 뻗어나간다.

이제 main 브랜치에서 굵은 가지가 하나 갈라져 나오는데 이를 개발 브랜치(develop)라고 한다. 새로운 기능이나 큰 변화는 개발 브랜치(develop)에서 자라기 시작한다.

기능 브랜치(feature)는 굵은 가지(develop)에서 다시 뻗어 나온 가느다란 가지다. 기능마다 가지가 하나씩 뻗어 나온다. 이 가지들은 자유롭게 자라다가 다 자란 뒤에는 다시 개발 브랜치(develop)로 합쳐진다.

릴리스 브랜치(release)는 나무가 꽃을 피우는 과정과 비슷하다. 하나의 큰 가지(develop)에서 꽃봉오리(release)를 만들어 최종적으로 줄기(main)로 보내 꽃(배포)을 피운다.

마지막으로 핫픽스 브랜치(hotfix)는 갑자기 생긴 병충해를 긴급하게 치료하는 가지이다. 줄기(main)에서 바로 뻗어 나와 빠르게 문제를 고친 뒤 다시 main 브랜치와 개발 브랜치(develop)로 병합한다.

스타카토의 Git 브랜치 전략

main, develop

스타카토의 나무 기둥은 main 브랜치이다. main 브랜치에서 develop 브랜치라는 굵은 가지가 뻗어나온다.

feature

feature 브랜치는 개인 작업을 진행하는 브랜치이다. feature 브랜치를 생성하기 위해서는 백엔드와 안드로이드 모두 이슈 티켓을 먼저 발행해야 한다. 이슈 티켓을 발행한 뒤에는 feature/#이슈번호-내용 형식으로 브랜치를 생성할 수 있다.

개인 작업이 완료되면 feature/#이슈번호-내용 브랜치에서 develop 브랜치로 PR(Pull Request)를 생성한다. PR은 리뷰를 진행하기 위한 장이라고 생각하면 된다. PR에서 리뷰를 진행하고 두 명 이상의 승인이 받으면 develop 브랜치로 feature 브랜치를 병합할 수 있다.

release

스타카토는 release를 위해 release-an/버전, release-be/버전 두 가지 브랜치를 생성한다. 안드로이드와 백엔드 브랜치를 나누는 이유는 CD 설정 때문이다. release-an으로 시작되는 브랜치에서 생성한 PR이 main 머지될 때만 Google Play Console에 AAB를 배포하기 위해 분야별로 별도의 release 브랜치를 관리한다.

🤔 여기서 잠깐.. 스타카토는 왜 많은 충돌을 경험했을까?

스타카토는 하나의 Repository를 안드로이드와 백엔드가 함께 사용하고 있다. 스타카토가 배포할 때마다 많은 충돌을 겪었던 이유는 다음과 같다.

1. main에서 hotfix를 적용한 후 develop을 최신화하지 않은 경우가 있다.(추정..)
2. 잦은 충돌로 main 브랜치를 제대로 활용하지 않은 적이 있었다.
3. main 브랜치의 변경사항을 develop 브랜치에 동기화하지 않은 적이 있다.
4. 개인 작업 중 local develop 브랜치를 origin develop과 동기화하지 않았을 수 있다.

결국 대부분의 충돌은 "최신화를 제대로 하지 않아서" 발생한 문제였다...!

즉, release 브랜치에서 main으로 배포를 완료한 후 반드시 origin/develop을 최신화하는 것이 가장 중요하다.

Outro

Git 브랜치 전략이나 코드 리뷰에서 가장 크게 느낀 점은 팀에 맞는 규칙과 전략을 찾는 것이 중요하다는 것이다. 무작정 좋은 방법을 따라 하기보다는 우리 팀에 적합한 방식을 찾는 것이 더 효과적이다.

참고자료

Inpa Dev [GIT] 📈 깃 브랜치 전략 정리 - Github Flow / Git Flow
사례로 이해하는 GitHub Flow
GitHub Docs: GitHub Flow