3️⃣ Github 설정
✅ 로컬 레포 → 원격 레포 연결 및 첫 푸시 순서
1️⃣ 로컬 프로젝트 디렉토리에서 터미널 켜기
.
2️⃣ Git 초기화 (이미 되어 있다면 생략)
git init
git status쳐서 초기화 여부 확인 가능
3️⃣ .gitignore 및 기본 파일 커밋 (선택)
git add . git commit -m "init: initial project setup".
4️⃣ 원격 레포 주소 확인 (GitHub에서 복사)
GitHub에서 만든 원격 주소 예시https://github.com/FE14-Team7-Taskify/Taskify.git또는 SSH 방식이면
git@github.com:your-org/taskify.git.
5️⃣ 원격(origin) 주소 등록
git remote add origin https://github.com/FE14-Team7-Taskify/Taskify.git✅ 확인하고 싶다면
git remote -v.
6️⃣ 브랜치 이름 확인 후 변경 (필요 시)
기본 브랜치가
main이면 그대로 사용하고,master일 경우 변경 가능git branch -M main.
7️⃣ 첫 Push
git push -u origin main•
-u는 이 브랜치를origin/main과 추적하도록 설정
• 이후부터는 그냥git push만 해도 됨
✨ 전체 요약
git init git add . git commit -m "init: initial project setup" git remote add origin https://github.com/your-org/taskify.git git branch -M main git push -u origin main.
💡 추가 팁
항목 설명
git remote remove origin 원격 연결 다시 하고 싶을 때 git remote set-url origin [URL] 원격 주소 변경할 때 .gitignore node_modules, .env 등 꼭 제외할 것
GitHub 설정
브랜치 자동삭제
Automatically delete head branches
•PR 머지후 사용된 브랜치를 자동으로 삭제한다.
• 브랜치 정리에 유용하며, 삭제된 브랜치는 복원 가능.
코드 리뷰 설정
현재 브랜치 전략은
Feture 브랜치에서 기능개발 이후develop 브랜치로 머지하는 방식으로 갈 것이다.
머지하기 전에 3명에게 코드리뷰를 받고 나서 개발한 본인이 머지할 수 있도록 설정을 해보자.1️⃣ Rulesets 기본 설정
🔹 Ruleset Name
• 이 룰셋의 이름을 설정한다 (예:
main 브랜치 보호용이라면main으로 네이밍).
• 나는develop 브랜치 보호용이기 때문에protect-develop으로 네이밍 했다.🔹 Enforcement status
• Disabled이면 아직 적용되지 않은 상태.
• 활성화하려면 Enabled로 바꿔야 설정이 적용됩니다.🔹 Bypass list
• 이 룰셋을 우회할 수 있는 사용자, 팀, 앱을 지정할 수 있다.
• 예: 관리자는 우회 가능하도록 설정 가능.
2️⃣ Targets (타겟 브랜치)
🔹 Target branches
• 보호하고자 하는 브랜치를 지정한다.
• 예:main,develop, 혹은release/*등 패턴도 사용 가능.
Add target클릭 →Include by pattern선택- 패턴에
develop입력
3️⃣ Require a pull request before merging 옵션
• ✅ 꼭 PR을 통해서만 머지 가능.
• 이 옵션을 체크해야 리뷰(Approve) 기반 머지를 강제할 수 있음.
옵션을 체크하면, 아래 추가 옵션들이 활성화된다. ⬇️
📌 Required approvals
•
PR을 머지하려면 최소 몇 명의 코드리뷰 승인이 필요한지 설정한다.
• 예: 3으로 설정 시, 3명 이상의 리뷰어가Approve해야만 머지 가능.
📋 추가 옵션 설명
1. ✅ Dismiss stale pull request approvals when new commits are pushed
•
PR에 새 커밋이 푸시되면, 기존에 받았던 승인을 무효화한다.
• → 코드 수정이 일어났다면 다시 리뷰를 강제하게 만드는 옵션.
• 보안 및 코드 품질 유지에 매우 유용합니다.
2. ✅ Require review from Code Owners
•
.github/CODEOWNERS 파일에 정의된 사람만이 리뷰를 승인할 수 있도록 제한한다.
• 모듈별 담당자가 코드 변경을 반드시 확인하도록 설정할 때 사용.
• 대규모 협업에서 책임 분산에 유리합니다.
3. ✅ Require approval of the most recent reviewable push
• 마지막으로 푸시된 커밋이 리뷰어 본인이 아닌 다른 사람에게 승인되어야 함을 강제한다.
• → 개발자가 본인 코드 머지 못 하도록 막는 용도.
• 리뷰 편법 방지 기능입니다.
4. ✅ Require conversation resolution before merging
•
PR내 코멘트들이 모두 해결 상태여야 머지 가능.
•unresolved comments(노란색 상태)가 남아있으면 머지 불가.
• → 리뷰 의견 무시하고 그냥 머지하는 걸 방지합니다.
5. ✅ Request pull request review from Copilot
•
GitHub Copilot이PR을 자동 분석해 리뷰 요청을 넣도록 설정한다.
• 단, 이건Copilot code review베타 권한이 있는 사용자만 사용 가능.
PR 템플릿
✅ PR 템플릿이란?
PR 템플릿은Pull Request작성 시 자동으로 입력되는 기본 양식이다.
개발자가 어떤 내용을 왜, 어떻게 수정했는지를 구조적으로 설명하도록 유도한다.
이는 팀 내 코드 리뷰 문화를 정착시키고, 프로젝트 관리 효율을 높이는 데 큰 도움이 된다.
🧠 왜 PR 템플릿이 필요한가요?
• 리뷰어의 이해도 향상: 변경 내용을 빠르게 파악할 수 있다.
• 일관된 커뮤니케이션: 팀원마다 PR 스타일이 달라지는 문제를 방지한다.
• 버그 예방: 체크리스트를 통해 누락된 작업을 사전에 방지한다.
• 기록 관리: 변경 목적과 배경이 기록으로 남아 히스토리 추적이 쉬워진다.
🛠 사용 방법
- 프로젝트 루트에
.github/PULL_REQUEST_TEMPLATE.md 파일생성
2. 아래와 같은 양식을 작성
3.GitHub에서PR생성 시 자동으로 템플릿이 적용된다.
PR 양식
# 🚀 Pull Request / ## 📝 PR 유형 <!-- 해당하는 유형에 'x'로 체크해주세요 --> - [ ] 기능 추가 (Feature) - [ ] 버그 수정 (Bug Fix) - [ ] 코드 개선 (Refactoring) - [ ] 스타일 변경 (UI/UX) - [ ] 문서 작업 (Documentation) - [ ] 환경 설정 (Configuration) - [ ] 기타 (Other) / ## 🔍 변경 사항 <!-- 이 PR에서 무엇이 변경되었는지 간략하게 설명해주세요 --> / ## 📸 스크린샷 <!-- UI 변경사항이 있다면 스크린샷을 첨부해주세요 --> / ## 🛠️ 테스트 방법 <!-- 이 기능을 테스트하는 방법을 설명해주세요 --> 1. 2. 3. / ## 🚧 관련 이슈 <!-- 관련 이슈 번호가 있다면 적어주세요 (e.g. #123 또는 ISSUE-123 과 같은 JIRA key) --> / ## 💡 추가 정보 <!-- 리뷰어가 알아야 할 추가 정보가 있다면 여기에 적어주세요 --> / ## 🙏 리뷰어에게 <!-- 리뷰어에게 특별히 확인받고 싶은 부분이 있다면 언급해주세요 -->아래 예시는 실제
PR예시이다!
