우아한 형제들 기술 블로그의 나동호님의 우린 Git-flow를 사용하고 있어요 글을 읽고 정리하였습니다.
Git Repository 구성
- Upstream Repository
- 개발자들이 공유하는 저장소
- 최신 코드가 저장되어 있는 원격 저장소
- Origin Remote Repository
- Upstream Repository를 Fork한 원격 개인 저장소
- Local Repository
- 내 컴퓨터에 저장되어 있는 개인 저장소
Workflow
(사진 출처: dev.to)
- Local Repository에서 작업을 완료한 후 작업 브랜치를 Origin Repository에 push
- Github에서 Origin Repository에 push한 브랜치를 Upstream Repository로 merge하는 Pull Request 생성
- 코드 리뷰를 거친 후 merge
- 다시 새로운 작업을 할 때 Local Repository에서 Upstream Repository를 pull
왜?
- 모두가 공유하고 있는 Upstream Repository에서 직접 개발하는 것은 위험하다.
- Origin Repository(Forked)를 두면 부담 없이 원하는 실험들을 해볼 수 있다.
- 브랜치의 생성, 삭제, 병합 등 git의 유연한 구조를 활용해서 각 개발자들의 혼란을 최대한 줄인다.
Git-flow의 5가지 종류 브랜치
- master: 제품으로 출시될 수 있는 브랜치
- develop: 다음 출시 버전을 개발하는 브랜치
- feature: 기능을 개발하는 브랜치
- release: 이번 출시 버전을 준비하는 브랜치
- hotfix: 출시 버전(master 브랜치)에서 발생한 버그를 수정하는 브랜치
Git-flow Model
- 처음에 Master와 develop 브랜치가 존재하며, develop 브랜치는 master에서부터 시작된 브랜치다.
- develop 브랜치에서는 상시로 버그를 수정한 커밋들이 추가된다.
- 새로운 기능 추가 작업이 있는 경우 develop 브랜치에서 feature 브랜치를 생성한다.
- feature 브랜치는 언제나 develop브랜치에서부터 시작한다.
- 기능 추가 작업이 완료되었다면 feature 브랜치는 develop 브랜치로 merge된다.
- develop에 이번 버전에 포함되는 모든 기능이 merge 되었다면 QA를 하기 위해 release 브랜치를 생성한다.
- QA를 진행하면서 발생한 버그들은 release 브랜치에 수정된다.
- QA를 모두 통과했다면 release 브랜치를 master와 develop 브랜치로 merge한다.
- 마지막으로 출시된 master 브랜치에서 버전 태그를 추가한다.
작업할 때 지켜야할 협업 원칙
- 커밋 크래프는 최대한 단순하게 가져간다.
- 서로 공유하는 브랜치의 커밋 그래프는 함부로 변경하지 않는다.
- 서로 공유하는 브랜치에 대한 반영사항은 반드시 Pull Request와 코드 리뷰, merge 과정을 거친다.
- 리뷰어에게 꼭 리뷰를 받는다.
- 자신의 Pull Request는 스스로 merge한다.
작업 브랜치와 feature 브랜치의 삭제 시점
- fork repository의 작업 브랜치들은 Pull Request를 요청 후 merge와 함께 삭제
- feature 브랜치 역시 develop 브랜치에 merge와 함께 삭제
