diff --git a/README.md b/README.md
index 601e962..fe32feb 100644
Binary files a/README.md and b/README.md differ
diff --git a/docs/Branch strategy and pull-request.md b/docs/Branch strategy and pull-request.md
new file mode 100644
index 0000000..8c8f1b3
--- /dev/null
+++ b/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/)
\ No newline at end of file
diff --git a/docs/Code Convention.md b/docs/Code Convention.md
new file mode 100644
index 0000000..c67f213
--- /dev/null
+++ b/docs/Code Convention.md	
@@ -0,0 +1,208 @@
+# `코드 컨벤션`
+
+<aside>
+☝ 명확한 의미 전달을 위해 축약형 사용을 지양합니다.
+
+</aside>
+
+<aside>
+☝ 작성한 코드를 팀원도 이해할 수 있도록 주석을 달아줍니다. → 선택
+
+</aside>
+
+<aside>
+☝ 패키지 이름은 소문자로 생성하고, 역할이나 기능에 따라 명확하게 묶어서 명명합니다. 언더스코어 ‘_’나 대문자를 섞지 않습니다.
+
+```java
+com.example.project.controller
+com.example.project.service
+com.example.project.repository
+com.example.project.model
+```
+
+</aside>
+
+<aside>
+☝ 상수는 대문자와 언더스코어(”_“)로, 변수와 메서드는 CamelCase 형식으로 작성합니다.
+
+```java
+// 상수
+static final int MAX_COUNT = 100;
+
+// 변수
+int itemCount;
+
+// 메서드
+public String printCount() { ... }
+```
+
+</aside>
+
+<aside>
+☝ 변수명을 짓기 어려울 때에는 아래 사이트의 도움을 받아봅시다!
+영어로 선택 후 원하는 단어를 검색하면 됩니다.
+
+[Curioustore](https://curioustore.com/#!/)
+
+</aside>
+
+<aside>
+☝ Boolean 타입의 변수는 접두사로 is를 사용해 변수명을 작성합니다.
+
+```java
+boolean isExist;
+boolean isTrue;
+```
+
+</aside>
+
+<aside>
+☝ long 타입의 값의 마지막에는 대문자 ‘L’을 붙여줍시다.
+
+```java
+long base = 54423234211L;
+```
+
+</aside>
+
+<aside>
+☝ 컬렉션 이름은 복수형을 사용하거나 컬렉션임을 명시해줍니다.
+
+```java
+List ids;
+Map<User, int> userMap;
+```
+
+</aside>
+
+<aside>
+☝ 클래스명은 명사로 작성하고 UpperCamelCase를 사용합니다.
+
+```java
+private class Address { ... }
+public class UserEmail { ... }
+```
+
+</aside>
+
+<aside>
+☝ 메서드명은 소문자로 시작하고 동사로 네이밍합니다.
+
+대표적인 메서드들의 네이밍 규칙은 아래를 따릅니다.
+
+```java
+// 조회(상세)
+getXXX()
+getXXXDetail()
+getXXXInfo()
+
+// 조회(리스트)
+getXXXList()
+
+// 조회(카운트)
+getXXXCount()
+
+// 등록
+createXXX()
+addXXX()
+registXXX()
+
+// 수정
+updateXXX()
+modifyXXX()
+
+// 삭제
+removeXXX()
+deleteXXX()
+```
+
+</aside>
+
+<aside>
+☝ Enum 변수의 이름은 대문자로 작성합니다.
+
+```java
+// 상태 - XXX_STATUS
+public enum MemberStatus {
+    WAITING_STATUS,    // 수락 대기 상태
+    ACCEPT_STATUS,     // 수락 상태
+    WITHDRAW_STATUS    // 탈퇴 상태
+}
+
+// 유형 - XXX_TYPE
+public enum UserType {
+    ADMIN_TYPE,
+    CUSTOMER_TYPE,
+    GUEST_TYPE;
+}
+```
+
+</aside>
+
+<aside>
+☝ builder를 호출하는 static 메서드는 다음 규칙을 따릅니다.
+
+1. 파라미터가 1개인 경우: **xxxFrom**
+
+```java
+public static User createUserFromUsername(String username) {
+    // username을 사용해 builder 호출
+    return new User(username);
+}
+```
+
+1. 파라미터가 2개 이상인 경우: **xxxOf**
+
+```java
+public static User createUserOf(String username, String email) {
+    // username과 email을 사용해 builder 호출
+    return new User(username, email);
+}
+```
+
+</aside>
+
+<aside>
+☝ 다른 객체로 변환하는 메서드의 이름은 toEntity 형식으로 선언합니다.
+
+```java
+@Getter
+public class ProductCreateRequest {
+    private ProductType type;
+    private ProductSellingStatus sellingStatus;
+    private String name;
+    private int price;
+
+		// AllArgumentConstructor는 private으로 직접 사용을 막아주고, 
+		// @Builder 선언해서 직접 사용 막기
+    @Builder
+    private ProductCreateRequest(ProductType type, ProductSellingStatus sellingStatus, String name, int price) {
+        this.type = type;
+        this.sellingStatus = sellingStatus;
+        this.name = name;
+        this.price = price;
+    }
+
+		// toEntity
+    public Product toEntity(String productNumber) {
+        return Product.builder()
+                .productNumber(productNumber)
+                .type(type)
+                .sellingStatus(sellingStatus)
+                .name(name)
+                .price(price)
+                .build();
+    }
+}
+```
+
+</aside>
+
+<aside>
+✅
+
+DTO
+____Response.java
+___Request.java
+
+</aside>
\ No newline at end of file