깃 브랜치 전략

DigginRoom flow(DRF) 전략 사용 규칙

• main 브랜치는 스프린트별 서비스 배포를 위한 브랜치로 둔다.
  • 서버의 main 브랜치는 서버의 배포를 위한 브랜치로 둔다.
  • 안드로이드의 main 브랜치는 안드로이드의 배포를 위한 브랜치로 둔다.
  • main은 무조건 테스트를 통과해야한다.
• feature/room
  • 각 커밋마다 체크(테스트 & Lint) 통과를 지향하지만 통과가 되지 않을 시 간단한 사유를 커밋에 메시지에 기재한다.
  • 체크가 통과되어야 머지될 수 있다.
  • 파트별 Main 브랜치에 PR을 날려 Approve를 받아 머지한다.
  • 스쿼시 머지를 사용한다.
  • 머지 후에도 스프린트가 종료될 때까지 브랜치를 유지한다.(삭제하지 않는다).
  • 각 파트별 main 브랜치에서 문제가 발생하면 hotfix 브랜치를 만들어서 이를 수정한다.

• feature/room

  • 각 커밋마다 체크(테스트 & Lint) 통과를 지향하지만 통과가 되지 않을 시 간단한 사유를 커밋에 메시지에 기재한다.
  • 체크가 통과되어야 머지될 수 있다.
  • 파트별 Main 브랜치에 PR을 날려 Approve를 받아 머지한다.
  • 스쿼시 머지를 사용한다.
  • 머지 후에도 스프린트가 종료될 때까지 브랜치를 유지한다.(삭제하지 않는다).
  • 각 파트별 main 브랜치에서 문제가 발생하면 hotfix 브랜치를 만들어서 이를 수정한다.

  브랜치명	역할	규칙
  main	아카이빙, 문서	단일 브랜치, 삭제하지 않는다.
  android-main	안드로이드 주요 브랜치	안드로이드 단일 브랜치, 베타/운영을 라벨로 구분한다.
  backend-main	백엔드 주요 브랜치	백엔드 단일 브랜치, 베타/운영을 라벨로 구분한다.
  feature	신규 기능 개발 브랜치	스프린트가 끝나면 일괄 삭제한다
  hotfix	버그 픽스 브랜치
  rollback	롤백 대응 브랜치

핫픽스 대응

• main 브랜치에서 급하게 대응해야하는 부분에 대해 hotfix 브랜치를 분기하여 처리한다.
• 이후 문제를 처리했다면 hotfix 브랜치를 main 브랜치에 pr을 보내 merge 한다.

롤백 대응

• 긴급 사고를 대응하기 위해 사용하는 경우
  • 커밋 자체를 지운다.
  • 예시) 비밀번호가 유출되었다면?(정말 긴급)
    • 롤백 커밋 불가
    • 커밋 자체를 지워야함
  • main 브랜치의 커밋 로그를 강제로 삭제한 뒤에 강제로 push를 한다.
  • 이를 통해 remote 레포지토리의 커밋 로그를 삭제한다.
• 롤백 브랜치를 통해 대응하는 경우
  • 롤백 커밋이 남는다.

깃 커밋 컨벤션

PR 머지

예시

chore: PR 템플릿 작성(#10)

허용되는 타입

• feat (기능 개발)
• fix (버그 픽스)
• docs (문서 작성)
• style (코드 리포맷팅, 세미콜론 누락 등)
• refactor (리팩터링)
• test (테스트 코드 추가)
• chore (build.gradle 등 설정파일)

예시) feat: 유저 엔티티 기능 개발