1. Commit

<aside> ➡️ Commit Message 의 구성 방법

[commit type]: [commit message]        -- 제목(코드 동작에 대한 설명)

- [optional body]                      -- 본문(생략 가능)

<Example>

feat: 로그인 기능 구현

- Security Config 설정
- userName, password 입력 화면 구현 완료

</aside>

<aside> ➡️ Commit Type

• 테스트 코드 추가 | | refactor | - 코드 리팩토링 (새로운 기능 추가 X , 버그 X)
• 파일 관련 수정, 이동, 삭제
• 스타일 관련 코드 (코드 포맷팅, 세미콜론 누락, 코드 자체의 변경이 없는 경우) | | chore | - feat이나 fix와 관련 없는 변경 사항, src나 test 파일이 아닌 다른 파일 수정 사항 (ex .dependencies 수정 같은 경우)
• 빌드 시스템이나 외부 종속성과 관련있는 코드
• 문서 수정 (README.md) | | fix | 버그 수정 | </aside>

2. Branch

<aside> ➡️ git flow

• prod(master): 배포
• dev: 개발
• feature: 기능
  • 해당 브랜치명은 FEAT/JIRA 티켓 번호 로 작성
• hotfix: 배포 후 버그 수정
  • 해당 브랜치명은 FIX/JIRA 티켓 번호 로 작성 </aside>

3. Pull Request

• 하나의 Issue에 하나의 PR을 해요.
• PR 제목은 [JIRA 티켓 번호] PR에 대한 간단한 요약으로 작성해요.
• PR 내용은 템플릿에 맞춰서 작성해요.

<aside> 📌 Pull Request Template

### 이슈 번호(링크) 
-- ex) #1 (링크) 
  
### 개요
-- 작업의 제목을 간단하게 적기
  ex) MusaSNS Mission 1 구현 

### 내용
-- 작업 상세 내용 적기(스크린샷, 어떤 코드를 왜 변경했는지)
  1. Post Response 형식에 맞게 수정
  2. SQL Exception 처리 

### 리뷰어들에게
-- 기능 구현에 대해 이슈사항 언급, 리뷰어가 집중하여 리뷰할 부분 등 자유로운 형식으로 적기
  * Service Test 코드를 저런 형식으로 작성하는게 맞을까요?
    혹시 다른 방법이 있다면 리뷰해주시면 감사하겠습니다!
	* 이런 부분들을 중점적으로 구현했습니다! 

</aside>

• Merge 조건
  1. PR을 올린 사람이 리뷰를 받은 후 직접 Merge해요
  2. 1명 이상에게 리뷰를 받았을 경우에 Merge가 가능해요

4. Code Review