docs : README.md 문서 작성

docs/Branch strategy and pull-request.md

@@ -0,0 +1,213 @@
+# `브랜치 전략과 풀 리퀘스트`
+
+
+## 브랜치 전략
+
+먼저 코드의 충돌나는 상황을 최대한 적게 하고 프로젝트를 배포할 때 수월하게 하기 위해서는 브랜치 관리를 잘하는 것이 중요합니다.
+
+따라서 아래와 같이 브랜치를 관리하려고 합니다.
+
+<br>
+
+### `main 브랜치`
+
+- develop 브랜치에서 배포할 수 있을 정도로 구현된 것을 Merge를 하는 브랜치입니다.
+
+<br>
+
+### `develop 브랜치`
+
+- 기능 개발과 버그 수정의 브랜치 Merge가 자주 일어나는 브랜치입니다. 한마디로 개발이 활발하게 일어나는 브랜치입니다.
+- 되도록이면 개발을 할 때 develop 브랜치에서 새로운 브랜치를 생성합니다.
+
+
+<br>
+
+### `feat(Label)/#이슈번호`
+
+
+- 본인이 이슈를 만들었던(기능) 것에 대한 기능을 개발하는 브랜치입니다. 기능이 완벽하게 구현이 되었다면 develop 브랜치에 Pull Request를 보낸 후에 Merge를 하면 됩니다.
+
+  ex) feature/#1
+
+<br>
+
+## Flow
+
+<aside>
+
+1) 이슈 템플릿에 맞춰 이슈 생성한다.
+
+`기능구현(feat)` | `오류해결(fix)` | `환경설정(chore)` | `리팩토링(refactor)`
+
+2) 브랜치의 이름은 태그이름/#{이슈넘버}-#{이슈이름}로 한다.
+   ex) feat/#21-회원가입
+
+3) commit message는 태그이름: 내용으로 커밋한다.
+
+   ex) feat: #{이슈번호} 회원가입 API 구현
+
+4) PR 템플릿에 맞춰 PR을 날린다.
+
+   4-1) 실행결과 스크린샷을 첨부해서 내용만 봐도 알 수 있도록 작성한다.
+
+   4-2) `close #{이슈넘버}` 로 merge 시 자동으로 이슈가 close 되도록 한다.
+
+5) merge할 때는 반드시 PR을 날려 최소 한 명의 팀원에게 **리뷰**받은 후 스스로 merge한다.
+6) main브랜치에 merge가 된 브랜치는 삭제한다.
+
+---
+
+</aside>
+
+## PR 규칙
+
+<aside>
+이슈넘버와 직관적인 변경사항으로 제목을 남긴다.
+Description에는 바뀐 부분에 대한 설명 및 review가 필요한 부분에 대해 자세하게 설명한다. 
+
+ex) [feat/#21] 회원 로그인 기능부분 구현 feat/#21 은 브랜치이름
+
+중요! `close #{이슈넘버}` 로 merge 시 자동으로 이슈가 close 되도록 한다.
+
+</aside>
+
+---
+
+## Commit Message
+
+**태그이름은 모두 소문자로 쓰고 아래 9개 중 하나로 쓰기**
+
+커밋은 최대한
+
+| feat: #{$이슈번호} | 새로운 기능 추가한 경우  |
+| --- | --- |
+| fix: #{$이슈번호} | 오류를 해결한 경우 |
+| design: #{$이슈번호}  | CSS등 UI변경한 경우 |
+| style: #{$이슈번호}  | 코드 포맷 변경, 세미콜론 누락, 코드 수정이 없는 경우 |
+| refactor: #{$이슈번호} | 코드의 리팩토링  |
+| docs: #{$이슈번호} | 문서와 관련하여 수정한 경우 |
+| test: #{$이슈번호} | test를 추가하거나 수정했을 경우  |
+| chore: #{$이슈번호} | build와 관련된 부분, 패키지 매니저 설정 등. 초기 설정도 여기에 포함 |
+| rename: #{$이슈번호} | 폴더 이름, 경로 변경한 경우 |
+| merge: #{$이슈번호} | 충돌 해결시 작성하는 커밋 메시지 |
+- ISSUE 템플릿
+    - error
+
+        ```markdown
+        ---
+        name: 오류 수정
+        about: 오류 설명 및 수정
+        title: "[fix]"
+        labels: "오류수정"
+        assignees: 'username'
+
+        ---
+
+        ## 🤔 오류 내용
+        에러로그 함께 입력  
+        <br>
+
+        ## ⚠ 에러 캡쳐 
+
+        <br>
+        ```
+
+    - feature
+
+        ```markdown
+        ## ✨ 구현 할 기능
+        - [ ] 
+        - [ ] 
+        - [ ] 
+
+        <br>
+
+        ### 📕 레퍼런스
+        ```
+
+    - refactor
+
+        ```markdown
+        ---
+        name: 리팩토링
+        about: 클린코드, 디렉토리 구조 변경
+        title: "[refactor]"
+        labels: "리팩토링"
+        assignees: 'username'
+
+        ---
+
+        ## ✨ 리팩토링 할 부분
+
+        <br>
+        ```
+
+    - setting
+
+        ```markdown
+        ---
+        name: 환경 설정
+        about: 개발 환경 세팅
+        title: "[chore]"
+        labels: "환경설정"
+        assignees: 'username'
+
+        ---
+
+        ## ✨ 세팅할 환경
+
+        <br>
+
+        ### 📕 레퍼런스
+        ```
+
+- PR 템플릿
+
+    ```markdown
+    ## 📢 기능 설명 
+    필요시 실행결과 스크린샷 첨부
+    <br>
+
+    ## 연결된 issue
+    연결된 issue를 자동을 닫기 위해 아래 {이슈넘버}를 입력해주세요. <br>
+    close #{이슈넘버}
+    <br>
+
+    ## ✅ 체크리스트
+    - [ ] PR 제목 규칙 잘 지켰는가? 
+    - [ ] 추가/수정사항을 설명하였는가?
+    - [ ] 이슈넘버를 적었는가?
+    ```
+
+
+---
+
+## 주의 사항
+
+**커밋은 나누어 진행하기**
+
+예를 들자면,
+
+`feat: 로그인 페이지 추가 && fix: 로그인 페이지 오류 수정`
+
+이렇듯 메세지에 다른 내용을 한번에 커밋할 수 있는데, 이는 롤백할 때나 커밋 히스토리 확인할 때 불편할 수 있기 때문에 아래 예시처럼 진행
+
+ex)
+
+```bash
+git add { 로그인 페이지 추가에 관한 파일 스테이징 }
+git commit -m "feat: #{$이슈번호} 로그인 페이지 추가"
+git add { 로그인 페이지 오류 수정에 관한 파일 스테이징 }
+git commit -m "fix: #{$이슈번호} 로그인 페이지 오류 수정"
+```
+
+위 예시처럼 각각 스테이징 및 커밋
+
+📕레퍼런스
+
+---
+
+[코드리뷰가 쏘아올린 작은공 | 우아한형제들 기술블로그](https://techblog.woowahan.com/2712/)
+
+[우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그](https://techblog.woowahan.com/2553/)