깃 브랜치 전략 (Git-flow , GitHub-flow)

깃 브랜치 전략

여러 개발자가 하나의 저장소를 사용하는 환경에서 효과적으로 활용하기 위해 나온 work-flow

브랜치의 생성, 삭제 병합 등 git 구조를 이용해서 혼란을 줄이며 관리하는 역할을 한다

> 브랜치 생성에 규칙을 만들어 협업을 유연하게 하는 방법론

 

 

브랜치 전략이 없으면?

• 어떤 브랜치가 최신 브랜치인지?
• 어디에 push를 해야할지?
• 배포 버전은 어떤걸 써야 하나?
• 핫픽스는 어떤 브랜치를 기준으로 해야하나?

 

 

Git-flow

사진 출처 : https://nvie.com/posts/a-successful-git-branching-model/

 

위 사진과 같이 Git-flow 는 5가지 브랜치가 존재한다

그 중 가장 중심이 되는 메인 브랜치는 master과 develop 브랜치이며, 이 두 브랜치는 무조건 있어야 한다.

나머지 merge시 사라지는 보조 브랜치는 feature, release, hotfix 3가지 브랜치이다.

 

• Master : 상용 서비스 배포하는 브랜치. (배포 가능한 상태만을 관리)
• Develop : 개발 브랜치로 이 브랜치를 기준으로 각자 작업한 기능을 merge. (배포할 것을 개발)
• Feature : 새로운 기능을 추가하는 브랜치. develop 브랜치로 들어간다.
• Release : 다음버전 출시를 준비하는 브랜치. develop 브랜치를 release로 옮긴 후 QA 테스트 진행. 그 후 master 브랜치로 합친다. (배포를 위한 최종적인 버그 수정)
• Hotifx : 상용 버전에 릴리즈 배포를 했으나, 급하게 수정되어야 하는 내용들을 작업할 때 사용한다. (배포한 버전 긴급 수정)

 

Git-flow 흐름

 

1. 신규기능 개발

  1. develop 에서 신규 개발을 위해 feature 브랜치 생성

  2. feature 브랜치에서 기능 완성 후 develop 브랜치로 merge

 

2. 라이브 서버 배포

  1.  feature 브랜치가 모두 develop 브랜치에 merge 되었다면 ( = 1번 수행 후) 

  2. QA 진행을 위해 release 브랜치를 생성

  3. QA 통과 후 master로 merge

  4. 동기화 위해 develop 에도 merge

 

3. 배포 후 관리

  1. master 에서 버그 발생 시, hotfix 브랜치 생성하여 버그 픽스 진행

  2. 픽스 후 master / develop 양 쪽 merge

 

 

 

 

GitHub-flow

Git-flow 방식이 GIt Hub에 적용하기 복잡하다는 판단에 따라 만들어진 관리 방식이다

Git-flow에 비해서 흐름이 단순해지고 규칙도 단순해졌다

 

이미지 출처 : https://brownbears.tistory.com/603

 

 

브랜치 생성

1. 새로운 브랜치는 항상 main에서 생성한다

2. GIt-flow 와 다르게 feature 나 develop 브랜치가 존재하지 않는다

3. master 브랜치는 언제든 배포 가능한 상태를 유지한다

4. 브랜치 이름은 명확히 작성하자

> 그러므로 기능 추가와 버그 픽스같은 브랜치 이름은 어떤 일을 하는지에 대해 작성해야한다

 

 

개발 / 커밋 / 푸쉬

1. 커밋 메시지 정확하게 입력해야한다.

2. 작업물을 수시로 push 하여 다른사람이 확인 가능하게 하자

3. 항상 원격지에 하고있는 일들을 올리기 > 다른사람과 공유 및 하드웨어 문제 예방

 

 

master에 merge 할 때 pull Request 생성

1. pull request는 코드 리뷰를 도와주는 시스템으로, 내가 짠 코드를 팀원들에게 리뷰를 받고

> 완료되었다면 master 브랜치로 merge를 진행한다

 

 

master 브랜치에 merge가 되고 push 되었을 때 즉시 배포

1. CI/CD 자동화 하여 main 브랜치에 배포되었을 때 테스트와 빌드를 자동으로 거친 후 이상이 없다면

> production(live) 에 자동으로 반영

2. merge한 이후 요청한 브랜치는 삭제

(CI : 빌드/테스트 자동화 과정 / CD : 배포 배포 자동화 과정)