GitHub Foundations #5 Domain 3-2: 협업 — Pull Request·코드 리뷰·Discussions

2026년 7월 29일 수요일

5 분 소요

협업 도메인의 후반부입니다. 전반부가 Issue를 중심으로 한 작업 추적이었다면, 이번 글은 GitHub 협업의 중심 절차인 Pull Request와 코드 리뷰, 그리고 Issue와 자주 비교되는 Discussions를 정리합니다. 같은 도메인 범위에 포함되는 GitHub Pages와 Wiki도 함께 다룹니다. 이 글은 시험이 묻는 각 기능과 상태의 정확한 의미에 집중합니다. PR을 팀에서 잘 운영하는 실무 관점은 Git 실무 워크플로우 #5 PR 운영 — 리뷰 단위·커밋 메시지·draft PR에서 따로 다뤘습니다.

Pull Request 라이프사이클 #

Pull Request는 브랜치의 변경을 다른 브랜치로 머지해 달라는 요청이자, 그 변경을 리뷰하는 대화 공간입니다. 시험 관점에서 라이프사이클의 각 단계를 정확히 알아 두어야 합니다.

생성 — 브랜치를 push하면 저장소 페이지에 Compare & pull request 버튼이 나타납니다. base가 변경을 받는 브랜치, compare가 변경을 보내는 브랜치입니다.
draft — 아직 리뷰받을 준비가 안 된 PR은 draft 상태로 열 수 있습니다. draft 상태에서는 머지 버튼이 비활성화되고, Ready for review를 눌러야 정식 리뷰 단계로 넘어갑니다.
리뷰 — 리뷰어가 코멘트를 달고 승인하거나 변경을 요청합니다.
머지 — 세 가지 방식 중 하나로 base 브랜치에 합류합니다.
정리 — 머지된 브랜치는 Delete branch 버튼으로 삭제합니다.

PR이 열려 있는 동안 같은 브랜치에 커밋을 push하면 PR에 자동으로 반영됩니다. PR을 닫고 다시 열 필요가 없다는 점, 그리고 draft에서 머지가 막힌다는 점이 자주 출제되는 지점입니다.

코드 리뷰 — 리뷰어, CODEOWNERS, 리뷰 상태 3종 #

리뷰어는 PR의 Reviewers 항목에서 직접 지정합니다. 저장소 차원에서 자동 지정하려면 CODEOWNERS 파일을 씁니다.

CODEOWNERS 예시

# 경로 패턴          소유자
*.js                @frontend-team
/docs/              @octocat
/infra/             @org/platform-team

CODEOWNERS는 경로 패턴별로 코드 소유자를 선언하는 파일로, 해당 경로를 건드리는 PR이 열리면 소유자가 리뷰어로 자동 지정됩니다. 파일 위치는 저장소의 루트, docs/, .github/ 세 곳 중 하나가 허용된다는 사실이 시험 포인트입니다.

리뷰를 제출할 때는 세 가지 상태 중 하나를 고릅니다.

리뷰 상태	의미
Comment	의견만 남깁니다. 승인도 반대도 아닙니다
Approve	변경을 승인합니다. 머지 요건의 승인 수에 집계됩니다
Request changes	수정을 요구합니다. 해결 전까지 머지를 막을 수 있습니다

코드 줄에 다는 코멘트에서는 suggested changes 기능으로 수정안을 코드 블록 형태로 제안할 수 있습니다. 작성자는 제안을 검토하고 Commit suggestion 버튼으로 즉시 커밋으로 반영합니다. 오타 수정처럼 작은 변경을 왕복 없이 끝내는 기능입니다.

PR과 Issue 연결 #

PR이 어떤 Issue를 해결하는지 연결하는 방법은 두 가지입니다.

PR 본문에 닫는 키워드(closes #12 등)를 적습니다. 전 편에서 다룬 대로 기본 브랜치에 머지될 때 Issue가 자동으로 닫힙니다.
PR 또는 Issue 사이드바의 Development 필드에서 수동으로 연결합니다. 효과는 닫는 키워드와 같습니다.

연결된 Issue는 PR 사이드바에 표시되고, Issue 쪽에서도 어떤 PR이 진행 중인지 보입니다.

Discussions — Issue와의 용도 구분 #

Discussions는 저장소에 붙는 게시판형 대화 공간입니다. 시험은 Issue와의 용도 구분을 자주 묻습니다.

구분	Issue	Discussions
용도	작업 추적 (버그, 기능, 할 일)	대화 (질문, 아이디어, 공지)
종결	해결되면 닫음	닫는 개념이 약함, 답변 채택으로 마무리
구조	시간순 코멘트	카테고리별 스레드, 중첩 답글

Discussions에는 Q&A, Ideas, Announcements, Show and tell 같은 카테고리가 있고, Q&A 카테고리에서는 질문자가 답글 하나를 Mark as answer로 채택할 수 있습니다. Announcements 카테고리는 관리 권한이 있는 사람만 새 글을 쓸 수 있습니다. 대화가 구체적인 작업으로 발전하면 Discussion을 Issue로 전환하는 기능도 있습니다. 정리하면 추적할 작업은 Issue, 결론이 열려 있는 대화는 Discussions입니다.

GitHub Pages — 저장소에서 정적 사이트로 #

GitHub Pages는 저장소의 파일을 정적 웹사이트로 호스팅하는 기능입니다. 협업 도메인의 범위에 포함되는 시험 포인트입니다.

사이트 종류 — 사용자·조직 사이트는 username.github.io라는 이름의 저장소에서 만들고 주소도 같습니다. 프로젝트 사이트는 임의 저장소에서 만들고 username.github.io/저장소명 경로로 서비스됩니다.
게시 소스 — 지정한 브랜치의 지정 디렉터리(루트 또는 /docs)에서 바로 게시하거나, GitHub Actions 워크플로로 빌드해 게시하는 두 방식이 있습니다. Jekyll 정적 사이트 생성기가 기본 지원됩니다.
가시성 — 공개 저장소에서는 무료 플랜으로 쓸 수 있고, 비공개 저장소의 Pages는 유료 플랜이 필요합니다.

Wiki — 저장소에 붙는 문서 공간 #

Wiki는 저장소에 붙는 간단한 문서 공간으로, 코드와 분리해 설명서나 설계 문서를 쌓을 때 씁니다. 각 페이지는 마크다운으로 작성하며 Wiki 자체도 별도의 Git 저장소로 clone할 수 있습니다. 문서를 코드와 같은 PR 흐름으로 리뷰하고 싶다면 Wiki보다 저장소 안의 docs/ 디렉터리가 낫다는 정도의 판단 기준까지 알아 두면 충분합니다.

노트

시험 포인트를 정리합니다. draft PR은 머지 버튼이 비활성화된다는 점, CODEOWNERS의 세 가지 허용 위치(루트, docs, .github), 리뷰 상태 3종 중 Request changes만 머지를 막는 효력을 가진다는 점, 그리고 작업 추적은 Issue, 열린 대화는 Discussions라는 구분이 이 영역의 단골 출제 지점입니다.

머지 3방식 복습 #

머지 버튼의 세 방식은 Git 트랙에서 이미 다룬 내용이지만 시험 관점으로 한 번 더 정리합니다.

Merge commit — 머지 커밋을 만들어 두 히스토리를 보존한 채 합칩니다.
Squash and merge — PR의 모든 커밋을 하나로 합쳐 base에 추가합니다. PR 하나가 커밋 하나가 됩니다.
Rebase and merge — PR의 커밋들을 머지 커밋 없이 base 위에 순서대로 다시 적용합니다.

저장소 설정에서 세 방식 중 허용할 것을 제한할 수 있다는 사실도 함께 기억해 둡니다.

마무리 #

협업 도메인 두 편을 마쳤습니다. PR 라이프사이클과 draft의 효과, CODEOWNERS와 리뷰 상태, Issue와 Discussions의 구분, Pages의 두 가지 게시 소스가 이번 글의 핵심입니다.

다음 글인 “GitHub Foundations #6 Domain 4: 모던 개발 — Actions·Codespaces·Copilot·Packages"에서는 GitHub를 개발 플랫폼으로 확장하는 기능들을 다룹니다. 특히 github.dev와 Codespaces의 차이는 시험 단골이므로 표로 정확히 비교하겠습니다.