GitHub 협업

Git을 익혔다면 이제 여럿이 함께 개발하는 법을 배울 차례입니다. GitHub는 Pull Request, issue, 코드 리뷰 같은 기능으로 협업을 매끄럽게 만들어 줍니다. 실무에서 가장 많이 쓰는 흐름을 정리합니다.

학습 목표

• fork와 clone의 차이를 안다.
• Pull Request(PR)의 역할을 이해한다.
• issue로 작업을 관리한다.
• 브랜치 → PR → 코드 리뷰 → 머지의 기본 협업 흐름을 따라 한다.

fork — 남의 저장소 복제하기

fork는 다른 사람의 GitHub 저장소를 내 GitHub 계정으로 통째로 복사하는 것입니다. 원본에 직접 push 권한이 없는 오픈소스 기여에서 주로 씁니다.

원본 저장소 (user/project)
      │  fork (GitHub에서 버튼 클릭)
      ▼
내 저장소 (me/project)  ── clone ──  내 컴퓨터

git clone https://github.com/me/project.git   # fork 한 내 저장소를 로컬로

팀 내부 저장소처럼 push 권한이 있다면 fork 없이 바로 clone해서 브랜치로 작업합니다.

issue — 할 일과 버그 관리

issue는 버그 신고, 기능 제안, 할 일을 기록·논의하는 공간입니다. 각 issue에는 번호가 붙고, 라벨·담당자·마일스톤을 달 수 있습니다. 커밋 메시지나 PR 본문에 #12처럼 번호를 쓰면 자동으로 연결되며, Closes #12라고 쓰면 PR이 머지될 때 해당 이슈가 자동으로 닫힙니다.

Pull Request — 변경을 합쳐 달라는 요청

Pull Request(PR) 는 "내 브랜치의 변경을 메인 브랜치에 합쳐 주세요"라고 요청하는 것입니다. PR 화면에서는 다음을 할 수 있습니다.

• 어떤 커밋·어떤 코드가 바뀌는지 한눈에 비교(diff)
• 동료의 코드 리뷰와 코멘트
• 자동 테스트(CI) 결과 확인
• 승인 후 머지

PR은 단순히 코드를 합치는 버튼이 아니라, 합치기 전에 검토하는 관문 역할을 합니다.

코드 리뷰

리뷰어는 PR의 변경을 보고 줄 단위로 코멘트를 남기거나, 승인(Approve) 또는 수정 요청(Request changes)을 합니다. 작성자는 피드백을 반영해 같은 브랜치에 다시 커밋·push하면 PR이 자동으로 갱신됩니다.

# 리뷰 피드백 반영
git add .
git commit -m "리뷰 반영: 입력값 검증 추가"
git push          # PR이 자동으로 업데이트됨

기본 협업 흐름 (브랜치 → PR → 머지)

가장 흔한 한 사이클은 이렇습니다.

# 1. 최신 main 을 받아 시작
git switch main
git pull

# 2. 작업용 브랜치 생성
git switch -c feature/signup

# 3. 작업하고 커밋
git add .
git commit -m "회원가입 폼 추가"

# 4. 원격에 브랜치 올리기
git push -u origin feature/signup

5. GitHub에서 feature/signup → main으로 Pull Request 생성.
6. 동료가 코드 리뷰 후 승인.
7. Merge 버튼으로 합치고, 작업 브랜치는 삭제.
8. 로컬에서 다시 최신화.

git switch main
git pull                       # 머지된 최신 main 받기
git branch -d feature/signup   # 끝난 로컬 브랜치 정리

main ●──●──●────────────◆  ← PR 머지
              \        /
feature/signup ●──●──●   (작업 → PR → 리뷰 → 머지)

요약

GitHub 협업의 핵심은 작업 브랜치에서 작업 → PR로 검토 → 머지라는 흐름입니다. fork는 권한 없는 저장소에 기여할 때, issue는 할 일·버그 관리에, 코드 리뷰는 합치기 전 품질을 지키는 데 쓰입니다. 다음 강좌에서는 이 모든 것을 잘 쓰기 위한 실전 팁을 정리합니다.