반갑개의 브랜칭 전략

🐶 저희 반갑개는 Git-flow를 사용하고 있어요!

• main : 구글 플레이에 배포된 최신 소스코드가 반영되어 있는 브랜치
• develop : feature에서 개발한 기능을 merge하는 브랜치 (개발 환경에 배포)
• feature : 기능을 개발하거나 리팩토링하는 브랜치
• release : 이번 출시 버전을 준비하는 브랜치
• hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치

🏃‍♂️ 코드를 작성하고 배포되기까지의 과정

1. 기능 요구사항을 작성한 issue를 생성한다.
2. 해당 issue에 대한 feature 브랜치를 만들고 코드를 작성한다.
3. 기능 개발이 완료되면 PR을 올린다.
4. 최소 2명 이상의 코드 리뷰 및 approve를 받는다.
5. 리뷰가 완료되면 squash and merge를 통해 develop 브랜치에 merge한다.
6. 배포 준비가 완료되면 release-1.0.0 브랜치에 merge한다.
7. 배포가 성공적으로 완료되면 main 브랜치에 merge한다.

📄 커밋 메시지 포맷

feat: 새로운 기능 개발

• Prefix
  • feat : 새로운 기능을 추가하는 경우
  • fix : 프로덕트 코드에 있는 버그, 도메인 잘못 이해해서 발생한 logical error, 기능적 결함 등
  • style : 공백이나 개행 수정, 코드 포맷 변경, 코드 수정이 없는 경우, import 순서
  • refactor : 리팩토링 (코드나 로직 변화는 있지만 기능 변화는 없는 경우), 패키지 구조 변경, 파일 이동, 클래스명 변경, 파일 삭제 등
  • comment : 주석 추가, 변경, 삭제
  • chore : 의존성 추가, yml 변경, java 파일 외 외부 파일 변경 (data.sql 등)
  • docs : 각종 문서를 수정한 경우 (readme, API 문서 등)
  • test : 테스트 관련 모든 커밋 (버그, 오류 수정, 리팩토링 포함)
    • 단, TDD 방식으로 테스트와 프로덕션 코드를 함께 작성하는 경우 feat 등을 사용한다.
  • remove : 기능 삭제
• 리팩토링 하면서 클래스명이나 패키지 구조를 변경하는 경우, 무조건 별도의 커밋이나 PR을 날린다.
• (커밋 메시지 예시) feat: 채팅 기능 추가

👑 PR 타이틀 포맷

[BE] feat: 새로운 기능 개발

🎟️ 미션

운영, 베타 배포용 브랜치

• 운영 배포용 브랜치: main
• 베타 배포용 브랜치: release
  • 베타 배포 후 QA가 완료되면 main으로 merge한다

핫픽스 대응

• release에서 hotfix 브랜치를 만들어서 대응한다.

롤백 대응

• 급한 롤백이 필요하면 구글 플레이에서 제공하는 롤백 기능을 활용한다.
• Git에서는 main 브랜치에서 tag로 버전을 관리하고, 해당 버전으로 롤백한다.