Git Flow 란 무엇일까?

Git을 이용하여 스프링 프로젝트를 하던 도중 git에 대한 심층적인 공부를 해야겠다는 생각이 문득 들었다. 협업을 하기 위해 많은 브랜치와 git flow가 있다고는 대충 들었지만 완벽하고 이해하고 이용하는 것과는 천차만별이라서 git flow를 공부하여 프로젝트에 적용시킬 계획이다.

 

기본 브랜치

feature -> develop -> release -> hotfix -> master 

 

-> 머지 순서는 앞에서 뒤로 진행

-> release와 hotfix 브랜치의 경우 develop 오른쪽에 위치하므로 develop도 머지 가능 

브랜칭 모델

=> 중심이 되는 브랜치는 master & develop! 

=> merge된 다른 브랜치는 삭제!

 

Feature 브랜치

• 새로운 기능을 추가하는 브랜치
• 나오는 곳 (Check out) : develop 
• 들어가는 곳 (Merge) : develop
• 이름 지정 가능

Release 브랜치

• 새로운 Production을 release 하는 브랜치
• 나오는 곳 (Check out) : develop 
• 들어가는 곳 (Merge) : develop, master
• 이름 지정 가능

Hotfix 브랜치

• Production에서 발생한 버그를 따내고 수정하는 브랜치
• 나오는 곳 (Check out) : master
• 들어가는 곳 (Merge) : develop, master

 

Git Flow 종류

 

GitHub Flow

• 흐름과 룰이 단순함.
• 자동화의 개념 내장
• master 브랜치는 언제든지 배포 가능함 (항상 최신 안정된 상태 유지 => 엄격 관리)

1. master에서 브랜치 따기
2. 원격 브랜치로 수시로 push
3. 피드백 도움 요청, merge 준비 완료 시 pull request 생성
4. 리뷰와 사인이 끝난 후 master로 merge
5. merge된 경우 즉시 배포

장점

> 브랜치 전략 단순

> 코드 리뷰 자연스럽게 가능

> CI가 필수적, 배포 자동 진행 가능

 

단점

> CI와 배포 자동화가 되어있지 않을 경우 사람이 관련된 업무를 진행한다는 점

> pr의 양이 많아질 경우 감당하기 어렵다.

 

GitLab Flow

• Github를 보완하기 위한 flow
• production 브랜치 존재 
• master와 production 사이 pre-production 브랜치 존재 -> staging을 위한 공간
• Github와 거의 유사하다.

 

내가 사용해야 할 Git Flow?

나는 Github Flow를 사용하기로 결정했다.

• 한번 경험해 보았음 (개인 프로젝트 이므로 전략이 단순)
• 코드 리뷰 가능

참고 : 잘 밤에 쓸데없는 생각하기.../Git flow, GitHub flow, GitLab flow (ujuc.github.io)