[Github] 브랜치 전략

밀크야살빼자·2023년 7월 24일

멋쟁이사자처럼 연합 프로젝트를 하면서 효율적인 협업을 위해 브랜치 전략을 도입하기로 했습니다. 다른 사람들과 공식적으로 협업하는 것은 처음이기에 브랜치 전략이 생소했습니다. 프로젝트 참여를 원활하고 효율적으로 하기위해 브랜치 전략이 무엇인지에 대해 알아보았습니다.

Branch 전략

멀티모듈은 여러 명의 개발자가 동일한 저장소를 사용하는 환경에서 효과적으로 작업하기 위해 도입된 개념입니다.
현재 거의 모든 기업들이 자체적인 상황에 맞는 멀티모듈 전략을 사용하고 있습니다.

대표적인 전략

GitHub flow
Git flow
GitLab flow

1. GitHub flow

GitHub Flow는 GitHub에서 만든 간단한 브랜치 전략입니다. 이 방법은 Master 브랜치를 중심으로 운영되며, 기능 개발과 버그 수정 등 모든 작업을 동일한 단순한 구조로 다룹니다. 특히 수시로 배포가 이루어지는 프로젝트에서 매우 유용하게 활용됩니다.

1) 브랜치 생성

기능 추가나 버그 수정을 위한 작업은 Master 브랜치로부터 새로운 브랜치를 생성하며, 이때 commit 메시지와 브랜치 이름을 정확하고 간결하게 작성해야 합니다. 모든 작업 브랜치는 Master로부터 분기됩니다.

2) 기능 개발, 버그 수정

작업을 진행하면서 각 기능별로 commit을 합니다.
이때 commit 메시지는 정확하고 간결하게 작성해야 합니다.
각 commit은 서버의 동일한 브랜치에 push되어야 합니다.(Git flow와의 차이점)

3) Pull Request 생성

기능 추가나 오류 수정이 완료되면 Pull Request(PR)을 보냅니다.

4) 리뷰와 논의

PR을 통해 팀원과 작성한 코드에 대한 리뷰와 논의를 합니다.

5) 공개 및 테스트

GitHub에서는 Master에 병합하기 전에 브랜치에서 코드를 공개하고 테스트할 수 있습니다.
PR을 통해 테스트가 완료되면 (테스트 버전으로) 공개할 수 있습니다.
오류가 발생할 경우 원래의 master 브랜치로 롤백하여 이전 상태로 돌아갈 수 있습니다.

2. Git-flow 전략

Vincent Driessen이 2010년에 제안한 Branch Model을 기반으로 만들어진 Git Flow는 현재 많은 기업에서 표준으로 사용되는 브랜치 전략입니다. Git Flow는 GitHub Flow와는 달리 크게 5개의 브랜치를 운영하여 코드를 관리합니다. 이 방식은 배포 주기가 길고 팀의 여력이 있는 경우에 적합합니다.

master : 제품으로 출시될 수 있는 브랜치
develop : 다음 출시 버전을 개발하는 브랜치
release : 이번 출시 버전을 준비하는 브랜치
- 브랜치가 분기되는 곳 : develop
  - 브랜치가 머지도는 곳 : develop & master
  - 이름 : release-*
  - 다음 버전 출시를 위해 QA를 진행하는 브랜치이다.
  - 버그 수정 및 버전 번호, 빌드 날짜와 같은 메타 데이터를 준비하여 기능 개발은 금지한다.
  - merge할 때는 --no-ff를 사용하여 기록을 그룹화한다.
  - master로 merge후에는 tag 명령을 통해 버전을 명시한다.
hotfix : 출시 버전에서 발생한 버그를 수정하는 브랜치
- 브랜치가 분기되는 곳 : master
- 브랜치가 머지되는 곳 : develop & master
- 이름 : hotfix-*
- production에 버그가 발생하면 빠른 수정을 위해 생성하는 브랜치이다.
- production코드를 수정하는 중에도 develop에서는 계속 개발을 할 수 있다는 장점이 있다.
- master로 merge후에는 tag 명령을 통해 이전 버전보다 높은 버전을 명시한다.
feature : 기능을 개발하는 브랜치
- 브랜치가 분기되는 곳 : develop
- 브랜치가 머지되는 곳 : develop
- 이름 : master, develop, release-* , hotfix-* 를 제외한 이름이 가능
- feature 브랜치는 하나의 새로운 기능을 만들 때 생성한다.
- develop에 merge후에는 삭제한다.
- merge할 때는 --no-ff를 사용하여 기록을 그룹화한다.

--no-ff란?

브랜치 전략에서 merge를 할 때 사용하는 것을 권장한다.

Fast-forward 관계에 있어도 Merge commit을 생성하여 해당 브랜치가 존재하였따는 정보를 남길 수 있다.

commit기록을 되돌리기 편해진다.

--no-ff를 사용하지 않으면?
브랜치의 존재 여부를 몰라 어떤 commit부터 해당 기능을 구현했는지 확인하기 어렵다.

메인 브랜치들의 특징

master와 develop 브랜치가 항상 유지됩니다.
master 브랜치는 제품으로 배포할 수 있는 브랜치입니다.
develop 브랜치는 개발자들이 개발을 진행하는 브랜치입니다.

보조 브랜치들의 특징

feature, release, hotfix 브랜치가 존재합니다.
사용이 완료되면 각 브랜치를 삭제합니다.

📜예시 설명

Master 브랜치에서 현재 15버전을 배포 중입니다.
1. Develop 브랜치에서는 15.5 버전의 기능을 개발 중입니다.
2. 다른 기능을 위해 Feature 브랜치를 생성하고 해당 기능을 개발합니다.
3. 다음 버전 개발 중에 현재 출시된 버전에 보안 문제가 발생하여 Hotfix 브랜치를 생성하고 보안 문제를 해결한 후 Master와 Develop으로 머지합니다.
4. 지속적으로 개발하여 15.5 버전의 기능들을 모두 개발하면 Develop 브랜치에서 개발이 완료되었다고 판단하여 Release 브랜치를 생성합니다.
5. Release 브랜치에서 QA와 베타 버전을 출시합니다. 만약 해당 브랜치에서 버그를 발견하면 해당 브랜치에서 버그를 수정합니다.
6. Release 브랜치에서 실제 사용자들에게 정식 배포할 준비가 되었다고 판단하면 Master에 배포하여 실제 사용자들에게 배포합니다. 동시에 Develop 브랜치에도 머지합니다.