Pull Request 흐름

5. 자주 하는 실수 (Tip)

❌ 실수 1. main 에서 바로 작업하고 나중에 브랜치를 만들려 함

브랜치 없이 커밋부터 쌓으면 PR 로 나누기 번거롭습니다. 작업을 시작하기 전에 switch -c 로 브랜치부터 만드는 습관이 필요합니다.

❌ 실수 2. push -u 를 빠뜨려 매번 원격·브랜치를 입력

-u 없이 push 하면 다음부터 git push origin feat/login 을 매번 풀어 써야 합니다. 첫 push 에 -u 를 붙이면 이후는 git push 만으로 충분합니다.

❌ 실수 3. 커밋 메시지 없이 "WIP" 만 남기고 반복 push

의미 없는 메시지가 쌓이면 리뷰어가 무엇이 바뀌었는지 커밋 목록만으로 알 수 없습니다. 커밋마다 무엇을 했는지 한 줄로 남깁니다.

❌ 실수 4. base 브랜치를 잘못 골라 PR 을 만듦

develop 에 올릴 브랜치를 main 대상으로 만들면 관련 없는 커밋까지 diff 에 섞입니다. PR 을 만들기 전에 브랜치를 어디서 땄는지 다시 확인합니다.

❌ 실수 5. 리뷰 지적마다 브랜치를 새로 만듦

지적 하나에 새 브랜치를 파면 PR 이 여러 개로 흩어집니다. 같은 브랜치에 커밋을 추가하고 push 하면 기존 PR 이 그대로 갱신됩니다.

❌ 실수 6. 리뷰 끝난 브랜치를 force push 로 덮어씀

이미 리뷰어가 읽은 커밋을 통째로 바꾸면 무엇이 새로 바뀌었는지 알기 어렵습니다. rebase 가 꼭 필요하면 --force-with-lease 를 쓰고 리뷰어에게 알립니다.

❌ 실수 7. PR 본문을 비워 두고 제목만 씀

본문이 비면 리뷰어는 코드만 보고 의도를 추측해야 합니다. 템플릿의 변경 내용·테스트 방법 칸을 채우는 것만으로도 리뷰 속도가 달라집니다.

❌ 실수 8. --no-ff 없이 병합해 PR 단위가 이력에서 사라짐

fast-forward 병합은 빠르지만 어디까지가 한 PR 이었는지 그래프에서 구분되지 않습니다. 관리자가 병합할 때는 --no-ff 로 병합 커밋을 남깁니다.

❌ 실수 9. 병합 후 브랜치를 지우지 않고 방치

오래된 브랜치가 쌓이면 목록에서 작업 중인 브랜치를 찾기 어렵습니다. 병합이 끝나면 원격·로컬 브랜치를 모두 지우고 fetch --prune 으로 정리합니다.

❌ 실수 10. Checks 탭의 실패를 확인하지 않고 병합 요청

CI 가 실패한 채로 리뷰를 요청하면 리뷰어가 같은 문제를 다시 지적해야 합니다. push 뒤에는 Checks 탭이 통과했는지 먼저 확인합니다.