Pull Request 흐름
2. 핵심 원리
2.1 PR 은 브랜치 병합 요청이다
PR 은 코드를 직접 옮기지 않고 "이 브랜치(compare)를 저 브랜치(base)에 합쳐도 되는지" 검토를 요청하는 기록입니다. 저장소 안에서는 두 브랜치의 차이와 대화 기록일 뿐이라 git log·git diff 만으로도 그 내용을 재현할 수 있습니다.
2.2 브랜치를 올리는 흐름
작업은 항상 최신 main 에서 새 브랜치를 만드는 것으로 시작합니다.
| 단계 | 명령 |
|---|---|
| 최신화 | git switch main && git pull |
| 브랜치 생성 | git switch -c feat/login |
| 커밋 | git add . → git commit -m "..." |
| 브랜치 올리기 | git push -u origin feat/login |
-u(--set-upstream) 를 한 번 쓰면 다음부터 git push·git pull 만으로 같은 브랜치를 주고받습니다.
2.3 base 와 compare
| 항목 | 의미 | 보통 값 |
|---|---|---|
| base | 병합될 대상 브랜치 | main 또는 develop |
| compare | 내가 작업한 브랜치 | feat/login |
base 를 잘못 고르면 관련 없는 커밋까지 diff 에 섞여 리뷰가 어려워집니다.
2.4 PR 제목과 본문
| 항목 | 담을 내용 |
|---|---|
| 제목 | 변경 요약 한 줄 (예: 로그인 폼 추가) |
| 변경 내용 | 무엇을·왜 바꿨는지 |
| 테스트 방법 | 확인한 절차나 명령 |
| 관련 이슈 | Fixes #12 같은 연결 키워드 |
2.5 PR 템플릿
.github/PULL_REQUEST_TEMPLATE.md 를 저장소에 두면 PR 본문 칸이 그 내용으로 미리 채워져 팀이 항목을 빠뜨리지 않습니다.
## 변경 내용
## 테스트 방법
## 관련 이슈여러 종류의 PR 이 있다면 .github/PULL_REQUEST_TEMPLATE/ 폴더에 파일 여러 개를 두고 고를 수도 있습니다.
2.6 드래프트(Draft) PR
아직 완성되지 않은 작업도 미리 올려 진행 상황을 공유할 수 있습니다. 리뷰 요청 버튼이 비활성화되어 실수로 병합되지 않으며, "Ready for review" 를 눌러야 보통 PR 로 바뀝니다. CI 는 드래프트 상태에서도 동일하게 실행됩니다.
2.7 PR 화면 구성
| 탭 | 내용 |
|---|---|
| Conversation | 설명, 리뷰 댓글, 상태 표시 |
| Commits | 이 PR 에 포함된 커밋 목록 |
| Files changed | 변경 파일과 diff, 줄 단위 댓글 |
| Checks | CI 실행 결과(빌드·테스트) |
2.8 로컬에서 PR 미리 보기
| 명령 | 보여주는 것 |
|---|---|
git log origin/main..feat/login |
Commits 탭에 실릴 커밋 목록 |
git diff origin/main...feat/login |
Files changed 탭에 실릴 diff |
git request-pull <base> <url> <브랜치> |
이메일로 보낼 리뷰 요청 본문 |
diff 의 ...(세 점)은 두 브랜치가 갈라진 시점부터의 차이만 보여줘 PR diff 와 정확히 같습니다.
2.9 리뷰 지적 반영
리뷰어가 수정을 요청하면 같은 브랜치에 커밋을 추가하고 다시 push 합니다. PR 은 브랜치를 계속 가리키므로 자동으로 갱신되며, 리뷰 흐름을 남기는 새 커밋 방식이 기본입니다. 합쳐 올리려면 commit --amend 나 rebase -i 후 push --force-with-lease 를 씁니다.
2.10 관리자 병합과 --no-ff
리뷰가 끝나면 관리자가 병합합니다. --no-ff 는 빨리 감기 병합을 막고 병합 커밋을 남겨 PR 단위가 이력에 그대로 보입니다(예제 4 그래프 참고). GitHub 화면의 초록색 "Merge pull request" 버튼도 내부적으로는 git merge --no-ff 를 실행합니다.
2.11 병합 후 정리
| 대상 | 명령 |
|---|---|
| 원격 브랜치 삭제 | git push origin --delete feat/login |
| 로컬 브랜치 삭제 | git branch -d feat/login |
| 삭제된 원격 브랜치 정리 | git fetch --prune |
GitHub 는 PR 병합 화면에 "Delete branch" 버튼을 함께 보여주지만, 로컬 정리는 각자 해야 합니다.
2.12 전체 흐름 요약
main -------------------------●(merge --no-ff)
\ /
feat/login●----●----●------
(커밋1) (커밋2) (리뷰반영)브랜치 생성 → 커밋·push → PR 생성 → 리뷰·반영 → 병합 → 브랜치 정리, 이 여섯 단계가 실무 PR 흐름의 뼈대입니다.