[Git] Git 브랜치 전략 : Git-Flow, Github-Flow, Gitlab-Flow

 

 

0. PR (Pull Request) 과정

1. git clone : github의 저장소 복제
   1. 브랜치 생성 및 이동
   2. 소스코드 작성 및 변경
2. git add : 작업 내용을 스테이징 영역에 저장
3. git commit : 변경 사항 저장
4. git push : 원격 저장소에 소스코드 올림
5. Pull Request : fork한 기존 저장소에 소스코드 반영

 

 

 

1. Git Flow

1.1. Branch

• master : 기준이 되어 제품을 배포하는 브랜치
• develop : 개발 브랜치
  • 개발자들이 이 브랜치로 각자 작업한 기능을 Merge
• feature : 단위 기능을 개발하는 브랜치
  • 기능 개발이 완료되면 develop 브랜치에 Merge
• release : 배포를 위해 master로 보내기 전, 먼저 QA(품질검사)를 하기 위한 브랜치
• hotfix : master 브랜치로 배포를 했는데, 버그가 생겼을 때 긴급 수정하는 브랜치

 

1.2. 과정

• master 브랜치에서 develop 브랜치 분기
• 개발자들은 develop 브랜치에 자유롭게 commit
• 기능 구현이 있는 경우 develop 브랜치에서 feature-* 브랜치 분기
• 배포를 준비하기 위해 develop 브랜치에서 release-* 브랜치 분기
  • 테스트 진행 시 발생하는 버그 수정은 release-* 브랜치에 직접 반영
• 테스트가 완료되면 release 브랜치를 master와 develop에 merge

 

 

 

2. Github Flow

• Git-flow가 복잡하다고 나온 전략
  • hotfix와 feature 브랜치를 구분하지 않고 우선순위를 다르게 한다
• 수시로 배포가 일어나며, CI와 배포가 자동화된 프로젝트에 유용

2.1. 과정

• master 브랜치는 어떤 때든 배포 가능
  • stable 상태로 product에 배포되는 브랜치이므로 엄격한 role과 함께 사용
  • merge 전 충분한 테스트 필요
• master 에서 새로운 일을 위한 브랜치를 만든다면, 이름을 명확히 작성
  • 브랜치는 항상 master에서 만든다
  • 브랜치 이름은 자세하게 어떤 일을 하는지 작성 (새로운 기능 추가, 버그 해결 등)
  • 커밋 메시지를 명확하게 작성
• 원격 프랜치로 수시로 push 하자
  • Git-flow와 상반
  • 항상 원격지에 자신이 하고 있는 일을 올려 다른 사람들도 확인 가능하도록 한다
• 피드백이나 도움이 필요할 때, 그리고 merge 준비가 되었을 때 pull request 생성
  • PR은 코드 리뷰를 도와주는 시스템
  • merge 준비가 완료되면 master 브랜치로 반영 요구
• 기능에 대한 리뷰, 논의가 끝난 후 master로 merge
  • 바로 product로 반영될 기능이므로 충분한 논의 이후 반영
    • 물론 CI도 통과 필요
• master로 merge되고 push되었을 때는 즉시 배포되어야 한다
  • master 로 merge가 일어나면 자동으로 배포 되도록 설정

 

 

 

3. Gitlab Flow

• Git-flow와 Github-flow의 절충안

3.1. Branch

• production
  • Git-flow의 master 브랜치 역할
    • Gitlab-flow의 master 브랜치는 production 브랜치로 병합
  • 오직 배포만을 담당
  • 이 브랜치에 릴리즈된 코드가 항상 프로젝트의 최신 버전을 유지할 필요 X
  • master 이상 권한만 push 가능
• pre-production
  • production 브랜치로 결과를 넘기기 전, 테스트를 수행하는 브랜치

 

3.2. 과정

• developer 권한 사용자는 master 브랜치에서 신규 브랜치 추가
• 신규 브랜치에서 소스를 commit하고 push
• merge request를 생성하여 master 브랜치로 merge 요청
• master 권한 사용자는 developer 사용자와 함께 리뷰 진행 후 master 브랜치로 merge
• 테스트가 필요하다면, master에서 production 브랜치로 merge 하기 전에 pre-production 브랜치에서 테스트

 

 

 

 

 

---

📌  References

https://velog.io/@kw2577/Git-branch-%EC%A0%84%EB%9E%B5

Git branch 전략(Git-Flow, Github-Flow, Gitlab-Flow)

https://inpa.tistory.com/entry/GIT-%E2%9A%A1%EF%B8%8F-github-flow-git-flow-%F0%9F%93%88-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EC%A0%84%EB%9E%B5

[GIT] 📈 깃 브랜치 전략 정리 - Github Flow / Git Flow