✍🏻 Convention

🖋️ Commit Message

• feat : 새로운 기능과 관련된 것
• fix : 버그(에러) 수정
• docs : Readme 수정
• style :
  • 안드로이드 → values 폴더 구현/수정 (theme, color 파일)
  • 웹백엔드→ 코드의 변화와 관련없는 포맷이나 세미콜론을 놓친 것 등
• refactor : 코드의 구조 개선(모듈화) / 기능의 변경이 없어야함
• test : test 코드 추가 및 수정
• chore
  • 안드로이드 → build.gradle 수정
  • 웹백엔드 → package.json / packagelock.json 수정

📁 Github branch 규칙

• main : default branch
• develop : dev branch
  • Android : develop/aos
  • Backend : develop/be
• feature/[aos/be]-기능명 : 기능 개발
  • ex. feature/new, feature/[]-login-api
• release
  • 스프린트 한 주 기능이 끝나면 fix 하는 브랜치로, 기능 추가말고 버그 수정과 refactor만 담당.
  • android / back 나누지 않고 일단 하나로

feature-branch 분리한 이유

• 가독성이 좋은 방향으로 정함
• dev branch 를 aos/be 로 나누었기 때문에 feature 도 분리

🤝 협업 규칙

• upstream 에서 브랜치(feature-branch) 생성 후 포크
• upstream 에서 새 기능 브랜치(feature-branch)를 생성합.
• 해당 브랜치를 포크(fork)하여 origin에 복사. - main only 옵션 해제
• 포크된 저장소를 로컬 컴퓨터로 클론(clone).
• 로컬에서 작업을 진행하고 커밋(commit).
• 변경 사항을 origin 에 푸시(push).
• origin 에서 upstream의 feature-branch에 대해 PR을 생성.
  • 리뷰 대상은 origin 의 feature → upstream 의 feature PR
  • 마지막에 PR 을 확인한 사람이 upstream feature-branch → develop 으로 머지

💻 Github 작업 방법

• Issue tracking 방법

  • 작업 내용을 TODO List로 담은 issue를 생성
  • branch 생성
    • feature/[aos/be]-기능명
  • commit 할때 issue tracking 하기
    • commit message 앞에 #{이슈번호} 붙이기
  • 작업 완료시 upstream 의 feature-branch 로 pull request
  • 마지막 리뷰어가 upstream develop 으로 머지

• merge 규칙

  • 급건 / 중요도 낮은 건은 선 merge 후 보고
  • 핵심 로직은 모든 contributor 가 review 후, 마지막 사람이 merge