CodePrep

🔹 18. 리뷰 이후의 작성자 역할 📌 18-1. 리뷰 피드백 반영 시 주의사항 ✅ 단순 수정이 아닌, 피드백의 의도 파악이 중요✅ PR에 리뷰가 달리면 "수정 커밋"으로 반영 → 리뷰 흐름 유지✅ 리뷰어가 남긴 질문에는 답글 또는 수정 이력으로 응답 📌 18-2. 리뷰어 제안을 수용하지 않을 경우 ✅ 이유 설명 → 논의 유도✅ 무시 ❌, 대화 ⭕ (기술적 근거 + 현재 컨텍스트 기반 판단)🔹 19. 리뷰어의 승인 기준 📌 19-1. Approve 판단 기준 ✅ 변경사항 충분히 검토 후 👍 Approve✅ 동작 확인, 코드 일관성, 사이드 이펙트까지 고려 ➡️ 단순 통과용 리뷰는 의미 없음 → 책임감 있는 승인 필요 📌 19-2. 승인 전 확인 포인트🔍 테스트 통과 여부📁 주요 파일 변경..

🔹 17. 리뷰어/작성자 역할 분담 기준과 매너 📌 17-1. PR은 "검토받을 준비"가 되었을 때만 생성👉 PR을 리뷰어에게 보내는 건 검토 요청이 아닌 검토 책임 이관 ➡️ 미완성/충돌 있는 PR은 혼란만 유발 ✔️ 리뷰 전에 아래 체크리스트 완료하기 : 🔍 git diff로 변경 내역 스스로 검토📂 누락된 파일 없는지 git status 확인📝 커밋 메시지 논리적이고 목적별로 구성📄 PR 설명에 기능 요약, 주의사항, 제외 파일 명시 📌 17-2. 리뷰어는 '방어적 리뷰'가 아니라 '협력적 리뷰'👉 단순 오류 찾기보다 개선 제안과 대안 제시가 핵심 ➡️ “이 부분 문제 있음”보다 “이런 방향은 어떨까요?”가 더 생산적✔️ 코드 컨벤션, 테스트 범위, 성능 영향까지도 함께 고려 📌..

🔹 16. 협업 효율을 높이는 브랜치 전략 📌 16-1. 브랜치는 목적별로 분리👉 기능 개발, 버그 수정, 실험 등 브랜치 목적을 명확히 구분 ✔︎ 예시 :• feat/login-auth• fix/board-comment-npe• test/image-upload ➡️ 브랜치 이름만 봐도 작업 내용을 알 수 있어야 함 📌 16-2. main/master 브랜치는 항상 배포 가능 상태 유지👉 직접 커밋 ❌ / 오직 PR을 통해서만 병합👉 긴급 핫픽스는 별도 hotfix/ 브랜치로 관리 ➡️ 품질 안정성과 신뢰도 확보 📌 16-3. PR은 작은 단위로 자주 보내기👉 2,000줄짜리 PR보다 200줄 PR이 리뷰와 테스트에 훨씬 유리 • 변경량이 많아질수록 리뷰 지연 → 병합 지연 → 갈등 발생 ..

🔹 15. 실수 없는 협업을 위한 커밋/PR 전략 📌 15-1. 커밋 단위를 작게, 논리적으로 구분👉 하나의 커밋에는 하나의 목적만 포함되도록 ✔️ 예 : "로그인 유효성 검증 추가" / "프론트 style 수정"은 별도 커밋으로❌ "로그인 + 리팩토링 + style 수정"을 한꺼번에 올리는 건 리뷰 불가능하게 만듦 📌 15-2. git status, git diff 없이 커밋하지 않기👉 커밋 전에 꼭 상태 확인git statusgit diff→ PR에 불필요한 변경사항이나 삭제된 내용이 올라가는 걸 방지→ .gitignore로 무시한 파일이 의도치 않게 영향 주는 것도 조기 확인 가능📌 15-3. PR 설명은 리뷰어의 눈높이에 맞게 작성👉 예시 :🛠️ 기능 추가: 게시판 글 수정 기능⚠️..

🔹 14. .gitignore은 무조건 파일을 무시하는 게 아니라, 추적 여부에 따라 달라짐 📌 14-1. .gitignore은 Git이 새로 추적할 파일만 무시함 👉 이미 Git이 추적 중인 파일은 .gitignore에 추가해도 계속 PR 대상이 됨👉 이 상태에서 해당 파일 내용을 지우고 커밋하면 → 빈 파일로 PR에 포함 → 코드 병합 시 실제 실행 중 오류 발생 가능 📌 14-2. 이런 문제를 방지하려면? ❗ 꼭 필요한 파일만 선택해서 add 후 커밋# 무조건 전체 add 하지 말고git add 원하는파일만.js# 이후 커밋git commit -m "의도한 파일만 커밋"# 그리고 PR 생성예 :• .gitignore에 application-local.yml 추가했는데 기존에 커밋..

🔹 13. PR 대상에서 제외된 파일이 있는 경우 .gitignore 설명 포함하기 📌 13-1. 환경 설정 파일 또는 개인 개발 설정 파일은 Git에 올리지 않음👉 보통 .gitignore에 아래와 같은 항목들이 포함되어 있음# IDE 설정.idea/*.iml# 빌드 결과물target/build/# 로그 파일*.log# 시스템 파일.DS_StoreThumbs.db# 환경설정application-local.ymlapplication-local.properties.env📌 13-2. PR 설명에 아래와 같은 코멘트 작성 권장🛠️ .gitignore에 의해 제외된 파일 목록 - application-local.yml 등 환경 설정 파일은 보안상 Git에 포함되지 않음 - 개발 환경에 따라 생기는..

🔹 12. main 최신 코드 기반으로 특정 파일만 수정 후 PR 보내기 📌 12-1. main 브랜치 최신 코드 반영 완료👉 이전 단계(#3)에서 이미 git pull origin main 수행한 상태 📌 12-2. 기능 브랜치 생성git checkout -b hotfix/수정-내용📌 12-3. 여러 파일을 수정한 경우, 그 중 하나만 커밋👉 아래처럼 원하는 파일만 선택적으로 커밋git status # 수정된 전체 파일 목록 확인git add src/.../TargetFile.java # PR에 포함할 단일 파일만 addgit commit -m "타겟 파일만 수정 커밋" ❗주의 : 다른 파일은 add 하지 않으면 PR 대상에 포함되지 않음📌 12-4...

🔹 9. main 브랜치 최신 코드 가져오기 (로컬 반영) 📌 9-1. 현재 작업 중이라면 먼저 저장👉 커밋 or stashgit statusgit add .git commit -m "작업 중이던 내용 임시 저장"# 또는git stash📌 9-2. main 브랜치로 이동git checkout main📌 9-3. 원격 저장소에서 최신 main 코드 가져오기 git pull origin main🔹 10. 최신 main 기준으로 새 기능 브랜치 만들기❗️보통 배포 이후의 신규 기능은 main 기준으로 시작하기 때문에 브랜치를 새로 파야함git checkout -b feature/새로운-브랜치명🔹 11. Spring 프로젝트(STS + Maven)에서 해야 하는 후속 작업 📌 11-1. STS에서..

✅ Pull Request(PR)로 브랜치 병합하기서비스 자동 병합 ❌ → 개발자가 직접 PR 올리고, 리뷰 후 develop에 병합하는 절차 🔹 8. 기능 개발 브랜치 작업이 끝났다면?PR(Pull Request)를 통해 develop에 병합 요청하는 방식으로 진행 📌 8-1. 기능 개발 완료 후 커밋 & 푸시# 변경사항 커밋git add .git commit -m "feat: 조회수 업데이트 기능 구현"# 기능 브랜치 푸시git push origin feature/update-view-count 💡 아직 develop에는 반영 ❌ , 반드시 GitHub에서 PR을 만들어야 병합이 이루어짐📌 8-2. GitHub에서 Pull Request 생성 1️⃣ GitHub 레포지토리로 이동2️⃣ Com..

🔹 1. GitHub 원격 레포지토리 연결하기 (최초 1회 설정) 📌 1-1. Git 사용자 정보 등록 (최초 1회만 설정)git config --global user.name "your-github-username"git config --global user.email "your-email@example.com"• Git 커밋 작성자 정보를 등록하는 단계• 전역 설정이므로 한 번만 하면 됨 📌 1-2. Git 프로젝트 초기화# 프로젝트 폴더로 이동cd "사용할 프로젝트용 폴더 경로"# Git 초기화git init• 현재 폴더를 Git 저장소로 초기화함📌 1-3. GitHub 원격 저장소 연결git remote add origin https://github.com/깃허브아이디/레포지토리이름.git..