Revise PR approval and add code review guidelines

Updated the approval requirement for PRs from 1 to 2 reviewers and added a section for code review timing and guidelines.

Author: seopgyu

README.md

@@ -16,14 +16,23 @@
 1. **이슈 생성** → 작업 단위 정의
 2. **브랜치 생성** → main 브랜치에서 이슈별 작업 브랜치 생성
 3. **Commit & Push**
-4. **PR 생성 & 코드 리뷰** → 최소 1명 승인 필요
+4. **PR 생성 & 코드 리뷰** → 최소 2명 승인 필요
 5. **Merge & 브랜치 정리**
     - 리뷰 완료 후 main 브랜치로 Merge
     - Merge 후 이슈별 작업 브랜치 삭제
 
 ---
 
-### 📌네이밍 규칙 총정리
+### 🧑‍💻 코드 리뷰 시간
+
+- 오전 스크럼 이후 진행, 오후 4시
+- 이슈 및 pr에 내용 자세하게 작성
+    - 팀원들이 이해하기 쉽게
+    - 이후 궁금한 사항 마이크 키고 질문!
+
+---
+
+## 📌네이밍 규칙 총정리
 
 | 구분 | 네이밍 예시 | 내용 |
 | --- | --- | --- |
@@ -32,78 +41,29 @@
 | 커밋 메시지 | feat(auth): JWT 기반 인증 구현 | type(scope): subject |
 | PR 이름 | [FE/feat] 로그인 기능 추가 | 이슈명과 동일하게 작성 권장 |
 
-## 🏷️ 이슈 이름 규칙 (Issue Naming)
-
-```css
-[작업영역/목적] 설명
-```
-
-✅ **예시**
-
-```bash
-[FE/feat] 로그인 기능 추가
-[BE/fix] 상품 목록 조회 오류 수정
-```
-
-| 구분 | 설명 |
-| --- | --- |
-| FE | Frontend 작업 |
-| BE | Backend 작업 |
-| feat | 기능 추가 |
-| fix | 버그 수정 |
-| docs | 문서 수정 |
-| refactor | 리펙토링 |
-| test | 테스트코드 작성, 수정 |
-
-### 브랜치 종류
-
-- **main** : 실제 배포 가능한 코드가 존재하는 브랜치
-- **feature** : 새로운 기능을 개발할 때 사용하는 브랜치
-- **refactor** : 작성된 코드를 리팩토링 할때 사용하는 브랜치
-- **fix** : 버그수정이나, 간단한 수정사항 적용할 때 사용하는 브랜치
-
-### 브랜치 네이밍 규칙
-
-```
-type/issue-number/description
-```
-
-- `type`: 브랜치의 목적 (ex. feat, fix, refactor,test 등)
-- `issue-number` (선택 사항): GitHub Issue 번호가 있다면 기입하여 작업을 추적
-- `description`: 브랜치에서 수행하는 작업을 간결하게 설명 (영문 소문자, 단어는 하이픈으로 연결)
-
-✅ **예시**
+1. **이슈 네이밍 규칙**
+    - 제목 규칙 : `[작업영역/목적] 설명`
+    - 예시 : `[BE/fix] 상품 목록 조회 오류 수정`
+    - 본문은 템플릿에 맞춰서 작성
 
-```smalltalk
-feat/#12/login-api
-fix/#34/order-bug
-```
-
-### 커밋 메시지 네이밍 규칙
-
-✔️ 팀원 누구나 커밋 히스토리를 보고 변경 사항을 쉽게 이해할 수 있도록 일관된 커밋 메시지 규칙을 따름
-
-```
-type(scope): subject
-```
-
-- `type`: 커밋의 종류. (아래 표 참고)
-- `scope` (선택 사항): 변경된 코드의 범위를 명시. (예: `auth`, `user-api`, `db`)
-- `subject`: 커밋에 대한 간결한 요약
-
-✅**예시**
+2. **브랜치 네이밍 규칙**
+    - 생성 기준 : `main` 브랜치에서 생성
+    - 명명 규칙  : `타입/#이슈번호/설명`
+    - 예시: `feat/#12/login-api'
+    
+3. **PR 네이밍 규칙**
+    - 제목 규칙 : `[작업영역/목적] 설명`
+    - 예시 : `[BE/feat] 로그인 기능 추가`
+    - 본문은 **📄 PR 템플릿**에 맞춰서 작성 + close #이슈넘버
 
-```makefile
-feat(auth): JWT 기반 인증/인가 구현
-fix(order): 결제 버그 수정
-docs: README 배포 방법 추가
-```
+4. **커밋 메시지 네이밍 규칙**
+    - `타입(범위) : 작업내용`
+    - 예시: `fix(order): 결제 버그 수정`
 
-- ✔️**참고**
-    
-    
-    | 커밋 타입 | 설명 |
+    | 타입 | 설명 |
     | --- | --- |
+    | FE | Frontend 작업 |
+    | BE | Backend 작업 |
     | `feat` | 새로운 기능 추가 |
     | `fix` | 버그 수정 |
     | `docs` | 문서 수정 ([README.md](http://readme.md/), API 문서 등) |
@@ -115,14 +75,6 @@ docs: README 배포 방법 추가
     | `remove` | 파일을 삭제하는 작업만 수행한 경우 |
     | `init` | 초기 생성, 꼭 필요한 라이브러리 설치하는 경우 |
 
-### Pull Request (PR) 네이밍 규칙
-
-✅**예시**
-
-```java
-[FE/feat] 로그인 기능 추가
-```
-
 ### **📄 PR 템플릿**
 
 - 개요
@@ -133,16 +85,8 @@ docs: README 배포 방법 추가
 - [이슈링크](https://github.com/prgrms-be-devcourse/NBE7-9-3-Team10/issues/61)
 - [pr링크](https://github.com/prgrms-be-devcourse/NBE7-9-3-Team10/pull/83)
 
-### 👥 PR 리뷰 안내
-
-- 팀원 간 PR 등록 시, 다른 팀원분들께서(가능하면 이전에 PR리뷰 해주신 횟수가 적으셨던 분 환영!) 조금만 시간을 내어 코드를 살펴봐주시고, 간단하게나마 리뷰를 작성해주시면 감사하겠습니다!
-- main 브랜치 보호 규칙
-- pr이 올라가는 즉시, pr리뷰를 담당해주시는 분 께서 잠깐 시간을 내주셔서 리뷰
-
-### ✅ Merge 기준
 
-- PR리뷰로 달아주신 사이드 이펙트나 리팩토링 거리 해결
-- ‘LGTM’, 또는 ‘좋은 거 같습니다.’ << 같은 이상없음 메시지를 다른 팀원분께 2건 이상 Approve 받으면 Merge 준비 완료
+---
 
 ### 📌참고
 
@@ -178,9 +122,3 @@ ex) `isVisible` |
 | 컴포넌트 | PascalCase |
 | 엔티티 | PascalCase |
 
-### 🧑‍💻 코드 리뷰 시간
-
-- 오전 스크럼 이후 진행, 오후 4시
-- 이슈 및 pr에 내용 자세하게 작성
-    - 팀원들이 이해하기 쉽게
-    - 이후 궁금한 사항 마이크 키고 질문!