[Git] branching model

Git flow

• 다양한 유형의 브랜치를 이용한 모델
• 각 브랜치에는 특정 목적이 있으며 분기 및 머지 정책에 대한 엄격한 규칙을 적용
• 아키텍쳐
  • 
• 주요 브랜치
  • 
  • 수명이 무한
  • default(main or master) 브랜치
    • 항상 프로덕션 준비 상태를 반영하는 브랜치
    • 커밋이 있을때마다 새로운 프로덕션 릴리스라 정의 가능하고 이때마다 자동으로 빌드하고 프로덕션 서버에 롤아웃 가능
  • develop 브랜치
    • integration 브랜치라 부르기도 함
    • 다음 릴리스에 대한 가장 최근의 개발 변경 사항이 있는 상태를 반영하는 브랜치
    • 자동 야간 빌드를 수행해야하는 브랜치
    • 해당 브랜치의 소스가 안정적인 지점에 도달하고 릴리스 준비가 되면 default 브랜치에 머지 후 태깅
• 서포트 브랜치
  • 팀 구성원 간의 병렬 개발을 지원, 기능을 쉽게 추적, 프로덕션 릴리스를 준비, 라이브 프로덕션 문제를 신속하게 수정에 도움이 되는 다양한 서포트 브랜치 사용
  • 주요 브랜치와 다르게 제거되어야 할 브랜치이므로 항상 제한된 수명을 가짐
  • Feature 브랜치
    • 
    • topic 브랜치라 부르기도 함
    • 향후 릴리스 또는 먼 미래 릴리스의 새 기능을 개발하는 데 사용하는 브랜치
    • 기능 개발을 시작할 때 이 기능이 통합될 대상 릴리스는 그 시점에서 잘 알려지지 않을 수 있음
    • 본질은 기능이 개발 중인 한 존재하지만 결국에는 다시 develop 브랜치로 머지되거나(다음 릴리스에 포함) 머지되지 않고 삭제(실험)
    • Feature 브랜치는 origin이 아닌 개발자 저장소에만 존재
    • develop 브랜치에서 분기하고 develop 브랜치에 머지
    • 머지 후 삭제
    • 명명 규칙
      • default(main or master), develop, release-, hotfix-를 제외한 모든 이름 가능
    • --no-ff를 사용할 것을 권장
      • 
  • Release 브랜치
    • 새 프로덕션 릴리스 준비를 지원
    • develop 브랜치에서 분기하고 default와 develop 브랜치에 머지
      • develop 브랜치가 새 릴리스에서 원하는 상태에 도달했을 때 분기
      • 사소한 버그 수정 및 릴리스에 대한 메타 데이터 준비(버전 번호, 빌드 날짜 등)를 허용
      • 분기 이후에 개발되는 내용은 develop과 Release 브랜치에 모두 반영하거나 릴리스 이후 develop 브랜치에 반영
      • 릴리스(default 브랜치에 머지) 후 태깅
      • 분기 이후 Release 브랜치에 수정된 내용이 향후 릴리스에도 포함되어야 하므로 develop 브랜치에도 머지
    • 대규모 새 기능을 추가하는 것은 엄격히 금지
    • 릴리스가 완료되면 삭제
    • 명명 규칙
      • release-*
  • Hotfix 브랜치
    • 
    • 계획되지는 않았지만 새 프로덕션 릴리스를 준비한다는 점에서 Release 브랜치와 유사
    • 라이브 프로덕션 버전에 즉시 조취를 해야하는 필요성에서 발생
    • 핵심은 다른 사람이 핫픽스를 준비하는 동안 팀 구성원의 작업(develop 브랜치)이 계속될 수 있다는 것
    • default 브랜치에서 분기하고 default와 develop 브랜치에 머지
      • 프로덕션 버전의 치명적인 버그가 즉시 해결되어야 하는 경우 프로덕션 버전을 표시하는 default 브랜치의 해당 태그에서 분기
      • 핫픽스(default 브랜치에 머지) 후 태깅
      • Release 브랜치와 마찬가지로 수정 내용이 향후 릴리스에도 포함되어야 하므로 develop 브랜치에도 머지
    • 한 가지 예외는 Release 브랜치가 현재 존재하는 경우 Hotfix 브랜치 대신 해당 Release 브랜치에 머지 후 릴리스
      • 릴리스가 완료될 때까지 기다릴 수 없을 정도로 개발 중인 작업에 해당 버그 수정이 필요한 경우 develop 브랜치에 같이 머지
    • 핫픽스가 완료되면 삭제
    • 명명 규칙
      • hotfix-*
• 장점
  • 명시적으로 버전이 지정된 소프트웨어를 빌드하거나 여러 버전의 소프트웨어를 지원해야 하는 경우 적합
• 단점
  • 상황에 따라 과도하거나 불필요한 절차로 인해 생상성 저하 가능성 존재

Github flow

• Scott Chacon이 Git flow의 복잡함을 해소하고자 만든 모델
• 경량화 된 분기 기반 워크플로
• 개발자 뿐만 아니라 사이트 정책, 문서 및 로드맵에 사용 가능
• default 브랜치에 대한 역할만 명확히 가져가며 다른 브랜치는 관여하지 않는 방식
• 절차
  • 브랜치 생성
    • default 브랜치를 기반으로 생성
    • feature 브랜치나 develop 브랜치를 관리하지 않으므로 브랜치 이름을 명확히 작성
  • 피드백을 요청할 준비가 될 때까지 계속 수정 및 원격 저장소에 푸시
    • 공동 작업자가 제안이나 기여 가능
  • default 브랜치로 풀 리퀘스트 생성
    • 공동 작업자에게 변경 사항에 대한 피드백을 요청
  • 리뷰
    • 리뷰어는 질문, 의견 및 제안을 작성
    • 리뷰에 따라 수정/커밋/푸시 반복이 가능하며 풀 리퀘스트는 자동으로 업데이트
  • 머지
    • 풀 리퀘스트가 승인되면 풀 리퀘스트가 default 브랜치에 자동으로 머지
  • 머지된 브랜치 삭제
    • 작업 완료의 의미
    • 실수로 해당 브랜치를 사용하는 것을 방지
    • 풀 리퀘스트 및 커밋 기록을 삭제되지 않음
• 장점
  • 단순
  • 자연스러운 코드 리뷰
• 단점
  • 배포, 환경, 릴리스 및 통합에 대한 문제가 남아있음
  • 규모가 커지면 관리가 어려움

Gitlab flow

• Github flow의 단순함(배포, 환경, 릴리스 및 통합에 대한 문제)과 Git flow의 복잡함(다양한 유형의 브랜치 사용)에 대한 추가 지침을 제공
• feature 브랜치
  • default 브랜치 기반으로 생성
  • 수정 후 default 브랜치로 머지 리퀘스트 생성
• default 브랜치
  • Git flow의 develop 브랜치 역할
  • 테스트 후 production 브랜치 혹은 pre-production 브랜치로 머지 리퀘스트 생성
• production 브랜치
  • Git flow의 default 브랜치 역할
  • Git flow에서 발생하는 머지, 릴리스, 태깅에 대한 오버헤드 방지
• pre-production 브랜치
  • production 브랜치에 머지전에 한번 더 확인하는 단계를 두고 싶을 경우 사용

Trunk-based development

• 하나의 브랜치(trunk 혹은 default)만 사용하는 방식
• 아키텍쳐
  • 소규모
    • 
  • 대규모
    • 
• 다른 브랜치를 임시로 사용하기도 하지만 수명이 매우 짧아야 함
  • 코드 리뷰, 테스트, 릴리스 등을 위해
  • 규모가 커진 경우 작업을 작게 쪼게 feature 브랜치를 사용
• 전제 조건
  • 탄탄한 개발 인프라
  • CI(Continuous Integration)
  • CD(Continuous Delivery)
  • 코드 리뷰
    • 페어 프로그래밍을 통해 코드 품질을 높이고 리뷰를 실시간으로 진행하는 것도 시간 지연을 줄이는 하나의 방법
    • 페어 프로그래밍을 하지 않더라도 코드 리뷰 요청에 대한 처리 우선 순위가 높아야 함
• 장점
  • 빠른 피드백
  • merge conflict가 발생하지 않음
• 단점
  • 전제 조건을 만족시키기 쉽지 않음