[Git] Git flow, 브랜치 별 역할

브랜칭 전략

: 브랜치의 종류를 나눠서 관리하는 전략

Git Flow

: 가장 유명한 브랜칭 전략 (by Vincent Driessen)

⬇

소프트웨어가 엄격한 버져닝이 필요하고, 여러 버젼을 배포해야 하는 경우

(하나의 소프트웨어 릴리즈 버젼을 명확히 나누고, 다양한 버젼을 배포하는 경우) 

git Flow가 적합하다. (= 애자일 방식에는 ㄴㄴ)

 

 

따라서, 

주어지는 개발 현장의 상황에 맞게 Git flow를 정하면 된다.

 

---

원조 Git flow 에서 파생된 여러 git flow

: Github flow, Gitlab flow

 

Coz' Git flow : 단순화된 Git flow

• main : 사용자에게 언제든 제품으로 출시할 수 있는 브랜치
• dev (=development) : 다음 버전 배포를 위한 "개발ing" 브랜치
• feat (=feature) /{작업이름} : 기능 개발, 리팩토링, 문서 작성 등을 위한 브랜치 

⬇

 

Main 브랜치 : 언제든 배포할 수 있는 브랜치

• 대표적 기능 완성
• 기존 기획했던 레이아웃, 디자인 얼추 완성ed
• 클라이언트, 서버, db가 공개된 웹에서 정상적으로 통신 가능
• 최소한의 보한 마련됨 (secret, 유저 비밀번호, 인증 토큰, 세션 등)

 

 

dev 브랜치 : 개발 중 브랜치 (다음 버전 배포를 위함)

• main 브랜치에서부터 브랜칭
• 프론트엔드 + 백엔드 결과 합쳐서 확인 가능해야 함
• Github 리포지토리에 늘 업뎃되어있을 것
• 팀원의 코드 리뷰와 함께 진행 (Pull Request 에서 코멘트)

 

 

feature 브랜치 : 다양한 작업 기록 (개발, 리팩토링, 문서 작업, 단순 오류 수정...)

hash (브랜치 명) 커밋 메시지
2f85eea (feat/create-todo) feat: Todo 추가 기능
2ad0805 (fix/var-name) fix: 변수 네이밍 컨벤션에 맞게 변수명 변경 (ismale => isMale)
e7ce3ad (refactor) refactor: 불필요한 for 루프 삭제

• 개인 로컬 리포지토리에서 만들고 작업
• 작은 기능이라도 브랜치 생성, 커밋, push로 결과 공유하는 것이 바람직
• squash-merge 전략 이용 (프리프로젝트 한정)