🐙 제이콥과 브라우니의 깃 컨벤션 🐙

6. Github Conventions

• 기본적으로 Git Flow를 준수한다.

• Release Branch 병합 완료 시 테스트 앱 테스터 배포
• Main Branch 병합 완료 시 릴리즈 앱 마켓 배포

6-1. 개발 프로세스

1. Issue를 생성한다.
2. feature Branch를 생성한다.
3. Add - Commit - Push - Pull Request 의 과정을 거친다.
4. Pull Request가 작성되면 작성자 이외의 다른 팀원이 Code Review를 한다.
5. Code Review가 완료되면 Pull Request 작성자가 develop Branch로 merge 한다.
6. merge된 작업이 있을 경우, 다른 브랜치에서 작업을 진행 중이던 개발자는 본인의 브랜치로 merge된 작업을 Pull 받아온다.
7. 종료된 Issue와 Pull Request의 Label과 Project를 관리한다.

6-2. Commit Convention

- [CHORE] : 동작에 영향 없는 코드 or 변경 없는 변경사항(주석 추가 등) or  라이브러리 추가, 새로운 파일 생성
- [FEAT] : 새로운 기능 구현
- [FIX] : 버그, 오류 해결
- [DOCS] : README나 WIKI 등의 문서 수정
- [REFACTOR] : 전면 수정
- [MERGE]: 다른 브랜치와 병합

• 커밋시, 이슈번호와 커밋 종류를 함께 명시한다.
  • [FEAUTRE/FIX … ] #이슈번호 : 커밋 메세지 형식
• ex) "[FEATURE]#1 : 회원가입 기능 완료"

6-3. Branch Convention

- [develop] : 최종 배포
- [feature] : 기능 추가
- [fix] : 에러 수정, 버그 수정
- [docs] : README, 문서
- [refactor] : 코드 리펙토링 (기능 변경 없이 코드만 수정할 때)
- [chore] : gradle 세팅, 위의 것 이외에 거의 모든 것

• 브랜치 생성 시, 브랜치 종류와 개발자 이름, 커밋 종류를 함께 명시한다.
  • 형식 : 브랜치종류/개발자이름/#이슈번호
• ex) : feature/jaino/#123