GitHub 시작하기

동작하는 코드

예제 1: GitHub CLI로 저장소 만들기

GitHub CLI(gh)를 설치하면 터미널에서 GitHub를 다룰 수 있습니다:

brew install gh
gh auth login

저장소 만들기:

cd ~/my-project
gh repo create my-project --public --push --source=.

이 명령어 하나로:

1. GitHub에 저장소 생성
2. origin 원격 연결
3. 현재 코드 push

확인:

gh repo view --web   # 브라우저에서 열기

예제 2: 이슈 만들기

gh issue create \
  --title "로그인 페이지 버그" \
  --body "비밀번호 재설정 후 자동 로그인이 안 됩니다."

출력:

https://github.com/username/my-project/issues/1

이슈 목록:

gh issue list

출력:

ID  TITLE                   LABELS  UPDATED
1   로그인 페이지 버그                  2분 전

예제 3: Pull Request 만들기

# feature 브랜치에서 작업 후
git checkout -b fix/login-bug
echo "// 버그 수정 코드" > login-fix.js
git add login-fix.js
git commit -m "fix: 비밀번호 재설정 후 자동 로그인 버그 수정"
git push origin fix/login-bug

gh pr create \
  --title "fix: 로그인 버그 수정" \
  --body "이슈 #1 해결

  ## 변경 내용
  - 비밀번호 재설정 후 세션 갱신 로직 수정"

직접 수정하기

Pull Request 코드 리뷰 사이클

PR을 만들면 팀원이 코드를 검토합니다:

개발자                           리뷰어
   │                               │
   │── PR 생성 ──────────────────→ │
   │                               │── 코드 검토
   │                               │── 코멘트 작성
   │ ←── 리뷰 피드백 ──────────── │
   │
   │── 수정 코드 커밋
   │── git push (PR 자동 업데이트)
   │
   │── 리뷰 재요청 ──────────────→ │
   │                               │── 재검토
   │                               │── 승인 (Approve)
   │ ←── 승인 ───────────────────  │
   │
   │── Merge PR
   │── 브랜치 삭제

리뷰 피드백 반영:

# 리뷰어가 "변수명을 더 명확하게" 코멘트를 달았을 때
vim login-fix.js   # 수정
git add login-fix.js
git commit -m "refactor: 변수명 명확하게 수정"
git push   # PR에 자동으로 반영

PR은 브랜치를 추적하므로 push하면 자동으로 업데이트됩니다.

PR 목록 및 상세:

gh pr list

gh pr view 1   # PR #1 상세 보기

gh pr view 1 --web   # 브라우저에서 열기

PR 병합:

gh pr merge 1 --squash   # squash merge (feature 커밋들을 하나로)
gh pr merge 1 --merge    # merge commit
gh pr merge 1 --rebase   # rebase merge

Draft PR: 진행 중임을 표시

# Draft PR: 아직 리뷰 준비가 안 됐을 때
gh pr create \
  --title "feat: 결제 시스템 구현" \
  --body "진행 중..." \
  --draft

Draft PR의 용도:

• "작업 중이니 아직 리뷰하지 마세요" 표시
• 진행 상황 공유
• CI 테스트 결과 확인
• 조기 피드백 요청

Ready for review 상태로 전환:

gh pr ready 1

"왜?" — GitHub가 단순 저장소 이상인 이유

GitHub는 Git 저장소 호스팅 + 협업 플랫폼입니다.

| 기능 | 역할 | | ---------------- | ---------------------------------- | | Issues | 버그 리포트, 기능 요청, 할 일 관리 | | Pull Request | 코드 리뷰 + 머지 요청 | | Actions | CI/CD 자동화 | | Projects | 칸반 보드로 작업 관리 | | Discussions | 팀 토론 |

Pull Request 워크플로우

이슈 생성 (#1 "로그인 버그")
    ↓
브랜치 생성 (fix/login-bug)
    ↓
코드 수정 + 커밋 (closes #1)
    ↓
PR 생성 (코드 리뷰 요청)
    ↓
코드 리뷰 + 피드백
    ↓
수정 반영 + 재검토
    ↓
승인 (Approve) → Merge
    ↓
브랜치 삭제 + 이슈 자동 닫힘

커밋 메시지나 PR 본문에 closes #1, fixes #1을 넣으면 PR 병합 시 이슈가 자동으로 닫힙니다.

CI 상태 확인

PR에서 GitHub Actions 결과를 확인:

gh pr checks 1

출력:

All checks were successful
✓ CI / test (2m 15s)
✓ CI / lint (45s)

CI가 실패한 상태에서는 병합을 막을 수 있습니다.

흔한 실수

실수 1: PR 제목이 불명확

# 나쁨
업데이트
수정
fix

# 좋음
fix: 비밀번호 재설정 후 자동 로그인 안 되는 버그 수정
feat: Google 소셜 로그인 기능 추가
docs: API 인증 섹션 추가

실수 2: PR에 너무 많은 변경 사항

# 피하세요: 한 PR에 수십 개 파일 변경
# 리뷰하기 어렵고 머지 충돌 위험 증가

# 권장: 한 PR에 하나의 목적
# "로그인 기능 추가" PR → login.js, auth.js, tests 관련 파일만

실수 3: 리뷰 없이 main에 직접 push

# 나쁜 습관
git push origin main   # 직접 push

# 좋은 습관
# 1. feature 브랜치 생성
# 2. 작업 + 커밋
# 3. PR 생성
# 4. 리뷰 받기
# 5. PR 병합

브랜치 보호 규칙을 설정하면 직접 push를 막을 수 있습니다.

심화 학습

# 원본 최신화 (upstream 설정)
git remote add upstream https://github.com/original/repo.git
git fetch upstream
git merge upstream/main

## 변경 내용

-

## 관련 이슈

closes #

## 체크리스트

- [ ] 기능 구현 완료
- [ ] 테스트 추가
- [ ] 문서 업데이트
- [ ] 브라우저 테스트

## 스크린샷 (UI 변경 시)