Git Convention

Commit Message

1. Basic Structure

• 기본적인 커밋 메시지 구조 (각 파트는 빈줄로 구분)

제목 ([Type] #Issue Subject)
(한줄 띄어 분리)
본문 (Body)

• 제목은 [Type] #Issue Subject 구조를 따른다.

2. Commit Type

Tag Name	Description
Feat	새로운 기능 추가
Fix	버그 해결
Docs	리드미 작성, 문서화 (Wiki)
Style	코드 format 변경 (변수명 변경)
Refactor	코드 개선, 리팩토링
Test	테스트 추가, 테스트 코드 리팩토링
Chore	github action으로 인한 yml 수정, project file 수정, gitignore 추가, 폴더 혹은 파일 삭제, asset 추가 등의 잡일

3. Subject

• 제목은 50글자 이내로 작성한다.
• 마침표 및 특수기호는 사용하지 않는다.
• 간결하고 요점적으로 즉, 개조식 구문으로 작성한다.

4. Body

• 72글자 이내로 작성한다.
• 최대한 상세히 작성한다. (코드 변경의 이유를 명확히 작성할수록 좋다)
• 어떻게 변경했는지보다 무엇을, 왜 변경했는지 작성한다.

5. Example

[Feat] #1 회원 가입 기능 구현

SMS, 이메일 중복확인 API 개발

참고자료: https://velog.io/@archivvonjang/Git-Commit-Message-Convention

Pull Request

1. Issue 완료 시 develop 브랜치로 PR
2. Message Convention

[#이슈번호] 작업 내용

ex) [#5] 팔로우 취소 기능 구현

3. 배포 전 Develop에서 Main으로 PR 올릴 때 템플릿

## 앱 스토어 업데이트 내용
- 

## 상세 내용
- 

## 배포 전 체크리스트
- [ ] url을 개발 서버로 변경하였는가? (`isProd = true`)
- [ ] Version과 Build 번호를 변경하였는가?
- [ ] Merge 하는 브랜치가 올바른가?
- [ ] 코딩 컨벤션을 준수하는가?
- [ ] PR과 관련없는 변경사항이 없는가?
- [ ] 내 코드에 대한 자기 검토가 되었는가?
- [ ] 오른쪽의 Development에서 이슈와 연결하였는가?

Git Branch 전략

Git Flow

Branch Name	Description
main	기준이 되는 브랜치로, 제품을 배포하는 브랜치
develop	개발 브랜치로, 개발자들은 이 브랜치를 기준으로 각자 작업한 기능들을 Merge
feature	단위 기능을 개발하는 브랜치로, 기능 개발이 완료되면 develop 브랜치에 Merge
release	배포를 위해 main 브랜치로 보내기 전에, 먼저 QA(품질검사)를 하기 위한 브랜치
hotfix	main 브랜치로 배포를 했는데 버그가 생겼을 때 긴급 수정하는 브랜치

• main 브랜치에서 develop 브랜치를 분기한다.
• 개발자들은 develop 브랜치에 자유롭게 커밋을 한다.
• 기능 구현이 있는 경우 develop 브랜치에서 feature-* 브랜치를 분기한다.
• 배포를 준비하기 위해 develop 브랜치에서 release-* 브랜치를 분기한다.
• 테스트를 진행하면서 발생하는 버그 수정은 release-* 브랜치에 직접 반영한다.
• 테스트가 완료되면 release 브랜치를 main과 develop에 merge한다.

• 브랜치명은 이슈번호-태그의 형식으로 만든다. ex) 3-feat/login

참고자료: https://velog.io/@kw2577/Git-branch-%EC%A0%84%EB%9E%B5

기타

• PR 병합 이후 해당 브랜치는 삭제한다. (같은 이름의 브랜치를 다시 생성하는 한이 있어도 일단 삭제)
• 작업을 완료하고 close한 이슈에서 수정사항이 생기는 경우, 별개의 작업으로 구분하고 그에 맞는 새 이슈와 새 브랜치를 생성하여 진행한다.