5장: GitHub로 협업하기 - Fork, Pull Request, 코드 리뷰¶

협업의 핵심: Pull Request¶

Pull Request(PR)는 "내 코드 확인해 주세요" 라는 요청입니다.

1. 내 브랜치에서 작업
2. GitHub에 push
3. Pull Request 생성
4. 팀원이 코드 리뷰
5. 승인 → main에 병합

두 가지 협업 방식¶

방식 1: 공동 저장소 (팀 프로젝트)¶

저장소에 직접 push 권한이 있는 경우:

# 1. 최신 코드 가져오기
git pull origin main

# 2. 작업 브랜치 만들기
git checkout -b feature/add-search

# 3. 작업 & 커밋
git add .
git commit -m "add search functionality"

# 4. GitHub에 push
git push -u origin feature/add-search

그 다음 GitHub 웹사이트에서: 1. 저장소 페이지로 이동 2. "Compare & pull request" 버튼 클릭 (또는 Pull requests 탭 → New pull request) 3. 제목과 설명 작성 4. Create pull request 클릭

방식 2: Fork & Pull Request (오픈소스 기여)¶

저장소에 push 권한이 없는 경우 (오픈소스 프로젝트 등):

원본 저장소 (upstream)
    ↓ fork
내 저장소 (origin)
    ↓ clone
내 컴퓨터 (local)

# 1. GitHub에서 원본 저장소를 Fork (웹에서 진행)

# 2. Fork한 내 저장소를 clone
git clone [email protected]:myname/project.git

# 3. 원본 저장소를 upstream으로 추가
git remote add upstream [email protected]:original-owner/project.git

# 4. 작업 전 항상 원본 최신 상태 가져오기
git fetch upstream
git checkout main
git merge upstream/main

# 5. 작업 브랜치 만들기
git checkout -b fix/typo-in-readme

# 6. 작업 & 커밋 & push
git add .
git commit -m "fix typo in README"
git push -u origin fix/typo-in-readme

# 7. GitHub에서 원본 저장소에 Pull Request 생성
# (base: 원본/main ← compare: 내/fix-typos)

Pull Request 잘 쓰기¶

좋은 PR 제목¶

feat: 사용자 검색 기능 추가
fix: 로그인 페이지 버그 수정
docs: API 문서 업데이트
refactor: 인증 모듈 리팩토링

좋은 PR 설명 템플릿¶

## 변경 내용
- 검색 기능 추가
- 검색 결과 페이지 구현

## 변경 이유
- 사용자가 게시글을 검색할 수 없는 문제 해결

## 테스트 방법
1. 검색바에 키워드 입력
2. 엔터 키 누름
3. 결과가 정상적으로 표시되는지 확인

## 스크린샷
(필요한 경우 추가)

커밋 메시지 컨벤션 (Conventional Commits)¶

<타입>: <설명>

타입 종류:
  feat:     새로운 기능
  fix:      버그 수정
  docs:     문서 수정
  style:    코드 포맷팅 (기능 변화 없음)
  refactor: 코드 리팩토링
  test:     테스트 추가/수정
  chore:    빌드, 의존성 등 기타 작업

예시:

git commit -m "feat: add user search with keyword highlighting"
git commit -m "fix: resolve login redirect loop on Safari"
git commit -m "docs: add installation guide for Windows"

코드 리뷰¶

리뷰 받을 때¶

PR은 작게 유지하기 (200~400줄 이하가 이상적)
이해하기 어려운 부분은 설명 남기기
피드백은 개인적인 공격이 아닙니다 — 코드에 대한 의견일 뿐!

리뷰 할 때¶

# 좋은 리뷰 코멘트 예시:
"이 함수에서 예외 처리를 추가하는 게 어떨까요? 입력이 null일 때 에러가 날 수 있습니다."

"여기서 `filter` 대신 `reduce`를 쓰면 성능이 더 좋을 것 같아요. 이유는..."

# 피해야 할 리뷰:
"이거 이상함"  (구체적인 이유가 없음)
"다시 해"       (어떻게 고쳐야 하는지 모름)

GitHub Issues: 할 일 관리¶

# Issues는 GitHub의 할 일 목록입니다
# 코드와 직접 연결되어 있어 편리합니다

Issue 활용법¶

버그 리포트: 재현 방법, 기대 동작, 실제 동작
기능 요청: 왜 필요한지, 어떻게 작동해야 하는지
질문: 코드 관련 질문

Issue와 PR 연결¶

# 커밋 메시지로 Issue 닫기
git commit -m "fix: resolve login error #12"
# → #12 Issue가 자동으로 닫힘

# PR 설명에서도 연결 가능
# "Closes #12" 또는 "Fixes #12" 를 PR 설명에 적기

GitHub Projects (칸반 보드)¶

GitHub에서 제공하는 프로젝트 관리 도구: - To Do: 해야 할 일 - In Progress: 작업 중 - Done: 완료

Issues와 PR을 칸반 보드에 연결해서 진행 상황을 시각적으로 관리할 수 있습니다.

.github 폴더: 프로젝트 설정¶

.github/
├── ISSUE_TEMPLATE/
│   ├── bug_report.md      # 버그 리포트 템플릿
│   └── feature_request.md # 기능 요청 템플릿
├── PULL_REQUEST_TEMPLATE.md  # PR 템플릿
└── CODEOWNERS               # 자동 리뷰어 지정

실전 워크플로우: 팀 프로젝트¶

매일 작업 시작:
  1. git pull origin main        # 최신 코드 가져오기
  2. git checkout -b feature/xxx   # 작업 브랜치 만들기
  3. 코드 작성
  4. git add . && git commit     # 자주 커밋하기
  5. git push -u origin feature/xxx

작업 완료:
  6. GitHub에서 PR 생성
  7. 팀원 코드 리뷰
  8. 피드백 반영
  9. 승인 → main에 병합
  10. git checkout main && git pull  # 최신 main 가져오기

규칙:
  - main에는 직접 push하지 않기
  - 항상 PR을 통해서만 병합
  - PR은 최소 1명 이상의 리뷰 승인 필요

실습 미션¶

GitHub에서 친구의 저장소를 Fork 해보세요
Fork한 저장소를 clone 하세요
원본 저장소를 upstream으로 추가하세요
새 브랜치를 만들고 작은 수정을 하세요
Push 후 원본 저장소에 Pull Request를 생성하세요
(친구에게) PR을 리뷰하고 승인/코멘트를 남겨보세요

이전 장: 04-git-remote.md 다음 장: 06-git-tips.md - 꿀팁과 고급 기능