[ Git ] 깃 브랜치 전략

개발을 하기로 했다면 Git 또는 SVN 을 사용하거나 들어봤을 것이다.

이러한 도구들은 개발자들이 팀으로 코드를 작성하는데 있어서 효율적으로 협업할 수 있도록, 코드를 관리하는데 도움을 준다.

깃에는 브랜치라는 하나의 줄기 ( 공통으로 개발하고 있는 코드 ) 에서 독립적으로 작업을 진행하기 위한 가지 ( 브랜치 ) 를 따서 작업하기 위한 장치를 제공하고 있다.

지금부터 이러한 브랜치를 통해서 협업하는 대표적인 3가지 방법에 대해서 알아보자.

1. Git-Flow

💡 사용되는 브랜치 종류
feature, develop, release, hotfix, master

feature

• 기능구현을 위한 브랜치로 일반적으로 feature/{ 구현 기능명 } 라는 명칭을 사용
• develop 브랜치에서 생성하여 기능 구현이 끝난 경우 다시 develop 브랜치로 머지
• 머지된 후에는 브랜치 삭제
• 보조 브랜치는 보통 개발자 저장소에만 있는 브랜치고, origin에는 push하지 않는다.

develop

• 다음 출시 버전을 대비하여 개발을 진행하는 브랜치
• 통합 브랜치의 역할을 하며 평소에 개발용으로 사용하는 브랜치

release

• 다음 버전 출시를 준비하는 브랜치. 테스트가 진행되는 브랜치
• develop 브랜치에서 생성하여 테스트 종료 후 master 브랜치로 머지

hotfix

• 배포중인 master 브랜치에서 발생한 버그를 수정하는 브랜치
• 버그에 대한 수정이 완료된 후에는 develop, master 에 곧장 반영해주며 tag를 통해 관련 정보를 기록해둔다.
• release 가지가 생성되어 관리되고 있는 상태라면 해당 가지에 hotfix정보를 병합시켜 다음번 배포 시 반영이 정상적으로 이루어질 수 있도록 해준다.

master

• 배포되는 소스가 있는 브랜치
• 태그를 통해 배포되는 버전을 관리

사용되는 브랜치의 수만 봐도 워크플로우가 복잡한 것을 알 수 있다. Git 을 사용하기 이전에 사용하던 SVN 과 같은 툴들이 하나의 브랜치를 사용하던 것을 감안하면 굉장히 복잡해졌다는 것을 알 수 있다.

💡 Git-Flow 를 사용하는데 적합한 프로젝트

• 정기적으로 배포가 필요한 경우
• 버저닝이 필요한 애플리케이션

Git-Flow 를 제안한 nvie 라는 개발자는 이렇게 말했다.

“Web apps are typically continuously delivered, not rolled back, and you don’t have to support multiple versions of the software running in the wild.”

웹 애플리케이션은 일반적으로 롤백되지 않으며, 지속적으로 서비스를 제공하기에 소프트웨어를 다양한 버전으로 지원할 필요가 없다.

“This is not the class of software that I had in mind when I wrote the blog post 10 years ago. If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.”

10년 전 블로그에 글을 쓸 때 이러한 소프트웨어를 염두하지 않았다. 만약 당신의 팀이 소프트웨어를 지속적으로 제공한다면 GitHub-flow와 같은 간단한 워크플로우 채택을 제안한다.

2. GitHub-flow

GitHub-flow는 Git-flow가 가진 복잡성을 전부 제거합니다. 유지 브랜치는 master 하나를 두는 방식으로 고수합니다. master를 제외한 브랜치는 개발자 재량에 맡기니 복잡한 정책이 필요치 않습니다.

자동화 개념이 들어가 있다라는 큰 특징이 존재하며 만일 자동화가 적용되어 있지 않은 곳에서만 수동으로 진행하면 된다.

흐름이 단순한 만큼 룰도 단순하다. master 브런치에 대한 role만 정확하다면 나머지 브런치들에는 관여를 하지 않는다. 그리고 pull request 기능을 사용하도록 권장을 한다.

GitHub-flow 정책

• master는 언제든지 배포가 가능하다.
• 새로운 프로젝트는 master를 기반으로 별도 브랜치를 생성하여 작업을 진행한다.
• 브랜치는 로컬에 commit하고, 정기적으로 원격 브랜치에 push한다.
• 피드백이나 도움이 필요하거나, 코드 병합할 준비가 되었다면 pull request를 만든다.
• 다른 사람이 변경된 코드를 검토한 뒤 승인하면 master에 병합한다.
• 병합된 master는 즉시 배포할 수 있으며, 배포 해야만 한다.

💡 Git-flow 를 사용하는데 적합한 프로젝트

• 상시 배포가 필요한 어플리케이션

3. GitLab-flow

Github에서 말하는 flow는 너무나도 간단하여 배포, 환경 구성, 릴리즈, 통합에 대한 이슈를 남겨둔 것이 많았다. 그것을 보안하기 위해 GitLab에서 관련 내용들을 추가적으로 덧붙여 설명한 것을 일컫는다.

GitLab은 GitHub-flow가 지속 배포 모범 사례라는 점에 동의합니다. 다만 배포, 환경, 릴리즈 및 소스 통합 등 다양한 이슈에 대한 궁금증을 GitHub가 답하지 않았다고 지적합니다. GitLab은 GitHub-flow를 기반으로 상황에 따라 워크플로우를 활용하는 방법에 대하여 추가적인 가이드를 제공합니다.

1. 배포 기간이 정해진 경우 발생하는 통합 이슈 해결책
2. 서버 환경에 따른 브랜치 구성 방법
3. 릴리즈 버전이 master와 분리되어 운영되어야 하는 상황 타개법

이 외에도 rebase를 활용한 commit 압축하기, merge commit 줄이는 방법, commit 메시지 작성 방법, 기능 분기에 대한 정책 등 다양한 방면에 대한 해답을 제시합니다. 그중에서도 GitLab이 내세운 건 이슈 기반 트래킹입니다.

‘코드를 변경하는 목적은 분명하므로 이슈로 생성하여 관리하자.’는 이념 아래로 코드 변경 사유를 투명하게 공개하자는 원칙입니다. GitLab은 동일한 repository를 사용하는 개발자들끼리 작업 내역을 알아야 된다고 말합니다. 또한 이슈를 기반으로 관리하면 브랜치 생명 주기가 보다 명확하게 파악되어 유지보수가 용이하죠.

참고

Git 브랜치 전략 수립을 위한 전문가의 조언들 – 화해 블로그 | 기술 블로그

[GIT] 📈 깃 브랜치 전략 정리 - Github Flow / Git Flow

Git flow, GitHub flow, GitLab flow

What is GitLab Flow?