Branch 브랜치 전략
- 여러 개발자가 협업하는 환경에서 한 개의 git 저장소를 효과적으로 활용하기 위한 work-flow
- 브랜치의 생성, 삭제, 병합이 자유로운 git의 유연한 구조를 활용하여 다양한 방식으로 소스 관리를 할 수 있다.
자주 쓰이는 브랜치 전략
- git-flow: 5가지의 브랜치를 이용해 운영하는 브랜치 전략
- github-flow: main 브랜치와 Pull Request 를 활용한 단순한 브랜치 전략
git-flow
- 많은 기업에서 표준으로 사용하는 브랜치 전략
- 항상 유지되는 2개의 메인 브랜치와 역할을 완료하면 사라지는 3개의 보조 브랜치로 구성
- 메인 브랜치: 항상 유지됩니다.
- main: 제품으로 배포할 수 있는 브랜치
- develop: 개발자들이 개발하는 브랜치
- 보조 브랜치: merge 되면 사라집니다. 사용을 마치면 브랜치 삭제
- feature: 기능을 개발하는 브랜치
- release: 이번 출시 버전을 준비하는 브랜치
- hotfix: 출시 버전에서 발생한 버그를 수정하는 브랜치
Feature 브랜치
- 브랜치가 분기되는 곳: develop
- 브랜치가 머지 되는 곳: develop
- 이름: master, develop, release-, hotfix- 를 제외한 이름 가능
- feature 브랜치는 하나의 새로운 기능을 만들 때 생성
- develop 에 merge 후에는 삭제
- merge 할 때는 —no-ff 를 사용하여 기록을 그룹화
—no-ff
- 브랜치 전략에서 merge 를 할 때 사용하는 것을 권장
- Fast-forward 관계에 있어도 Merge commit 을 생성하여 해당 브랜치가 존재하였다는 정보를 남길 수 있다.
- commit 기록을 돌리기 편해진다.
- 사용하지 않으면 브랜치의 존재 여부를 몰라 어떤 commit 부터 해당 기능을 구현 했는지 확인하기 어렵다.
Release 브랜치
- 브랜치가 분기되는 곳: develop
- 브랜치가 머지 되는 곳: develop & master
- 이름: release-*
- 다음 버전 출시를 위해 QA를 진행하는 브랜치
- 버그 수정 및 버전 번호, 빌드 날짜와 같은 메타 데이터를 준비하며 기능 개발은 금지 된다.
- merge 할 때는 -no-ff 를 사용하여 기록을 그룹화
- master로 merge 후에는 tag 명령어를 통해 버전을 명시
Hotfix 브랜치
- 브랜치가 분기되는 곳: master
- 브랜치가 머지 되는 곳: develop & master
- 이름: hotfix-*
- 제품 (master) 에 버그가 발생하면 빠른 수정을 위해 생성하는 브랜치
- 제품 (master) 코드를 수정하는 중에도 develop 에서는 계속 개발을 할 수 있다는 장점이 있다.
- master 로 merge 후에는 tag 명령을 통해 이전 버전보다 높은 버전을 명시
git-flow 개발 프로세스
- 개발자는 develop 브랜치로부터 본인이 개발할 기능을 위한 feature 브랜치를 만듭니다.
- feature 브랜치에서 기능을 만들다가, 기능이 완성되면 develop 브랜치에 merge 합니다.
- 이번 배포 버전의 기능들이 develop 브랜치에 모두 merge 됬다면, QA 를 위해 release 브랜치를 생성합니다.
- release 브랜치에서 오류가 발생한다면 release 브랜치 내에서 수정합니다. 마침내 QA 가 끝났다면, 해당 버전을 배포하기 위해 main 브랜치로 merge 합니다. bugfix 가 있었다면 해당 내용을 반영하기 위해 develop 브랜치에도 merge 합니다.
- 만약 제품 (main) 에서 버그가 발생한다면, hotfix 브랜치를 만듭니다.
- hotfix 브랜치에서 버그 픽스가 끝나면, develop 과 master 브랜치에 각각 merge 합니다.
git-flow 특징
- 주기적으로 배포를 하는 서비스에 적합
- 가장 유명한 전략, 많은 IDE가 지원한다.
github-flow
- github 에서 만든 단순한 구조의 브랜치 전략
- 제품이 릴리즈 되는 최신 버전인 main 브랜치만이 존재
github-flow 개발 프로세스
- 브랜치 생성
- 기능 개발, 버그 픽스, 혹은 어떠한 이유로든 main 으로부터 branch 를 생성
- git-flow 처럼 체계적 분류가 없기 때문에 브랜치 의도가 잘 들어나게 이름 작성
- 기능 개발, 버그 수정
- 작업을 하며 기능별로 commit
- commit 메시지는 정확하고 간결하게 작성해야한다.
- commit 은 서버의 동일한 브랜치에 push 해줘야 한다.
- Pull Request 생성
- 기능 또는 오류 수정이 완료되었으면 main 브랜치에 PR 을 보낸다.
- 리뷰와 논의
- PR을 통해 팀원과 작성한 코드에 대한 리뷰와 논의를 한다.
- 공개 및 테스트
- Github 에서는 main 에 합치기 전에 브랜치에서 코드를 공개 및 테스트 가능
- PR 상의와 테스트가 끝난 경우 (테스트 버전으로) 공개할 수 있다.
- 오류가 발생할 경우 원래의 main 브랜치를 다시 배포하여 roll back 한다.
- 합치기 Merge
- 브랜치의 검증이 완료되면 메인 브랜치에 합친다.
- 배포 자동화를 이용해 즉시 배포
github-flow 특징
- 브랜치 전략이 단순하여 git을 처음 접하는 사람에게도 유용
- CI (지속적 통합), CD (지속적 배포) 가 자연스럽게 이루어진다.
🧑🏻💻 Hello World!