C
협업 & Git/협업/Lesson 04

협업 — GitHub Flow · PR · 코드 리뷰 · 커밋 컨벤션

45분·theory

협업 — GitHub Flow · PR · 코드 리뷰 · 커밋 컨벤션

🎯 이 lesson 을 읽고 나면

이 lesson 을 다 읽고 나면 아래 3가지를 자신 있게 할 수 있습니다.

  • ✅ Pull Request / Code Review 표준 흐름
  • ✅ PR Template + Test plan 작성
  • ✅ feature flag + 점진적 배포

학습 목표를 체크리스트로 두고 다 답할 수 있게 되면 lesson 을 닫으세요.

GitHub Flow — 가장 단순한 협업 패턴

1. main 에서 분기git checkout -b feature/awesome
2. 작업 + 자주 push — 커밋 + 즉시 push (백업 + CI 트리거)
3. PR 일찍 생성Draft PR — 작업 진행하며 동시에 리뷰 가능
4. 토론·수정 — 코멘트 → 추가 커밋 → CI 재실행
5. 승인 + 머지 — 리뷰 OK + CI green → main 머지
6. 자동 배포 — CD 가 main 을 운영에 자동 배포 (보통 5 분 내)

> 💡 Git Flow 와 차이: develop/release 브랜치 없음. main 한 줄만 + feature 분기. SaaS 에 최적.

Pull Request 6단계 사이클

1. 브랜치 + 커밋 — feature 에서 작업 + 커밋 + push
2. PR 생성 — GitHub Compare & pull request → 제목·설명 작성
3. CI 자동 실행 — GitHub Actions 가 빌드·테스트·린트 자동
4. 동료 리뷰 요청 — Reviewers 지정. Slack·이메일로도 알림
5. 토론·수정 — 코멘트 → 추가 커밋 → 자동 갱신. 승인까지 반복
6. 머지 — 승인 + CI 통과 → main 머지. 브랜치 자동 삭제

좋은 PR 제목:

  • fix bug
  • fix(auth): JWT 만료 처리 - 401 응답 + refresh 토큰 재발급

좋은 PR 설명 (template):

markdown
## 변경 사항
- 무엇을 바꿨나

## 이유
- 왜 필요했나

## 테스트
- 어떻게 확인했나 (스크린샷·테스트 결과)

## 관련 이슈
Closes #123

코드 리뷰 6원칙

1. 코드를, 사람 X — "이 부분 X" 아닌 "이렇게 하면 어떨까?". 인격 공격 X
2. 질문형 — "왜 이렇게?" ✅ / "이건 잘못" ❌. 토론 유도
3. 이유 + 제안 — "NPE 가능성. null 체크 어떨까?" — 문제 + 해결책 함께
4. 우선순위 표시[Blocking]·[Suggestion]·[Nit] 중요도 명시
5. 좋은 점도 칭찬 — "이 부분 깔끔!" — 긍정 피드백 격려
6. 학습 자료 첨부 — 관련 문서·블로그 링크 — 함께 성장

리뷰어 체크리스트:

  • [ ] 코드가 PR 설명과 일치하는가
  • [ ] 테스트가 충분한가
  • [ ] 네이밍이 명확한가
  • [ ] 에러 처리·엣지 케이스
  • [ ] 보안 (시크릿·SQL injection·XSS)
  • [ ] 성능 (N+1·불필요한 계산)

커밋 컨벤션 — Conventional Commits

형식: <type>(<scope>): <description>

type 종류:

type의미예시
feat새 기능feat(auth): JWT 발급 추가
fix버그 수정fix(api): null 응답 처리
refactor리팩토링refactor(db): Repository 분리
docs문서docs: README API 섹션 갱신
test테스트test(auth): 만료 케이스 추가
chore빌드·설정chore: pnpm 9 업그레이드

자동화 혜택:

  • git log --grep "^feat" — feat 커밋만 보기
  • CHANGELOG 자동 생성 (semantic-release)
  • SemVer 자동: feat=minor / fix=patch / BREAKING CHANGE=major
  • commitlint 로 CI 에서 컨벤션 위반 PR 차단

> 💡 한국어 메시지도 OK. 핵심은 type prefix이유 명시.

💻 📌 협업 워크플로우 명령어 모음
# === GitHub Flow 한 사이클 ===
# 1. main 최신 동기화
git checkout main
git pull origin main

# 2. feature 브랜치 분기
git checkout -b feature/awesome

# 3. 작업 + 자주 commit + push
git add .
git commit -m "feat(awesome): 핵심 로직 추가"
git push -u origin feature/awesome

# 4. PR 생성 (GitHub CLI)
gh pr create --title "feat: awesome 기능" \
             --body "## 변경\n..." \
             --reviewer @teammate

# 5. PR 상태 확인
gh pr status
gh pr checks                  # CI 결과
gh pr view                    # 리뷰 코멘트 보기

# 6. 리뷰 반영 후 추가 커밋
git add .
git commit -m "refactor(awesome): 리뷰 반영 - null 체크 추가"
git push                      # PR 자동 갱신

# 7. 머지 (승인 + CI green 후)
gh pr merge --squash --delete-branch
# 또는 GitHub UI 의 'Squash and merge' 버튼

# === 좋은 커밋 메시지 예시 ===
git commit -m "feat(auth): JWT 발급 + refresh 토큰

- POST /api/auth/login → access·refresh 토큰 발행
- access 15 분 / refresh 7 일
- httpOnly cookie 로 refresh 저장 (XSS 방어)

Closes #42"

# === 변경 통계 ===
git shortlog -sn --since="1 month ago"   # 개인별 커밋 수
git log --author="홍길동" --oneline       # 특정 사람 커밋
gh pr list --author "@me" --state merged  # 내가 머지된 PR

🤖 AI 에게 이렇게 요청해보세요

이 lesson 의 개념을 알면 AI 에게 구체적으로 지시할 수 있습니다. 막연한 "고쳐줘" 가 아니라 어휘를 가진 요청 — 그게 토큰 절약의 출발점입니다.

  • "이 PR 본문을 "## Summary / ## Test plan / ## Risks" 템플릿으로 다시 써줘"
  • "이 코드 리뷰에 효과적인 코멘트 (질문형 + 대안 제시) 예시 3개 알려줘"

왜 이게 토큰을 줄이나

개념을 모를 땐 AI 답변을 받고도 "그게 뭐예요?" 를 다시 물어야 합니다. 그 "다시 물음" 이 토큰을 잡아먹습니다. 개념 한 번 익혀두면 대화가 한 번에 끝납니다.

협업 — GitHub Flow · PR · 코드 리뷰 · 커밋 컨벤션 - 협업 & Git