[Git]Git Flow/Github Flow/GitLab Flow

 

Git 브랜칭 전략

 ▶ 참고링크

 

Git-flow

브랜치

• 필수
  • master
  • develop
• 서포트
  • feature
  • release
  • hotifx

장점

• 명령어가 있다.
• 데이터와 IDE에 플로그인으로 존재

단점

• 브런치가 많아 복잡
• 안쓰는 브런치 존재

▶ 배달의 민족 - git flow 사용법

 

 

---

 

 

Github-flow

요약

• master 브런치에 대한 role만 정확하다면 나머지 브런치들에는 관여 X
• pull request 기능을 사용하도록 권장

 

장점

• branch 구성 전략이 단순하다.
• 처음 git에 대해 접하는 사람에게는 좋은 시스템이 되어준다.
• Github사이트에서 제공해주는 기능을 모두 사용해 작업을 진행하게 도와준다.
• 코드 리뷰를 자연스럽게 사용할 수 있다.
• CI가 필수적이며 또한 배포를 자동으로 진행할 수 있다.

 

단점

• CI와 배포 자동화가 되어있지 않은 시스템에서는 사람이 해당 업무를 진행해야 한다.
• 프로젝트의 규모가 커짐에 따라 점점 관리에 어려움이 발생할 수 있다

•  

 

 

---

 

 

GitLab-Flow

 

요약

• master-production 사이에 staging 브랜치를 두어 개발 내용을 바로 반영하지 않고 시간을 두고 반영
• github-flow 단점인 안정성 배포 시기 조절을 production 추가 브랜치를 두어 보강하는 전략

 

브랜치

• master
  • 개발을 위한 브랜치(기능 구현에 초점) \- pull request를 거친 커밋들이 자유롭게 올라간다.
  • production의 배포와 관계가 없다. \- 배포 주기에 구애받지 않는다.
• staging
  • develop에서 배포가 확정된 커밋들이 존재
  • staging은 지속적으로 유지가 되는 브랜치 \- 배포 가능한 빌드를 staging 빌드로 테스트 가능
  • 실제 production 환경에서 테스트 \- 배포 기능과 버그 수정에 집중
• production
  • 실제 배포가 되는 브랜치
  • staging에서 테스트 후 production으로 merge가 되면 배포가 완료