우크라이나어 하는 개발자

git-flow

중앙 repository에 메인 branch 2개(develop, master), 개발 멤버 리포지토리에 서포트 branch 3개(feature, release, hotfixes)가 있는 형태이다.

• 브랜치 설명
  • main branch
    1. master : 배포용 브랜치, 배포 시마다 태그 부여
    2. develop : 개발용 브랜치, 배포 전 최신 버전 유지
  • support branch
    1. feature : develop에서 생성, 기능 개발용
    2. release : develop에서 생성, 배포 준비용
    3. hotfix : 배포 제품에서 장애 발생 시 긴급 생성

git-flow 전략은 주기적인 배표 기간이 있는 대규모 프로젝트에 어울린다.

github-flow

• git-flow 문제점
  • git 사용도 어려운데 브랜치 전략은 더 어렵다
  • GUI 도구를 사용할 때 git-flow 스크립트를 사용할 수 있어 브랜치 전략에 개발자가 익숙해야 한다
  • git-flow 스크립트와 브랜치 전략 모두 이해하기 어렵다

github-flow는 git-flow 보다 단순한 구조이다.

• master는 어떤 때에든 배포 가능하고 항상 최신 상태 유지
• master에서 직접 브랜치 생성 (기능 추가, 버그 해결)
• 생성된 브랜치와 커밋 메시지는 명확하게
• 작성한 브랜치는 로컬 장치에서 커밋하고 원격 레포지토리에도 정기적으로 push 한다
• 개발이 완료되면 master에 Pull Request 한다
• Pull Request 검증하고 master에 merge 후 배포한다.

github-flow 주의점

• master는 배포용이기 때문에 직접 수정하지 않는다
• 작업 시작 시 브랜치를 생성한다
• 작업 종료 후 master에 Pull Request 한다

github-flow 보다 좀 더 복잡하게

우크라이나 학습 사이트 개발 프로젝트는 github-flow에서 한 브랜치를 추가하려고 한다. git-flow 브랜치에서 main branch가 develop과 master로 나누어져 있다. develop는 개발/테스트 브랜치로 사용하고 master 브랜치는 배포할 때 사용한다. 그리고 master는 develop에서 머지할 때마다 태그를 바꾸는 식으로 하기로 한다.

어떻게 보면 gitlab-flow와 비슷하다

Reference

• gitlab-flow
• Git flow, GitHub flow, GitLab flow
• Git 브랜치 전략 : Git-flow와 Github-flow
• Git-flow, A successful git branching model
• Github-flow
• '성공으로 이끄는 팀 개발 실천 기술', 제이펍, 2016년