코드 리뷰와 병합 방식

5. 자주 하는 실수 (Tip)

❌ 실수 1. 승인 없이 병합부터 시도

필수 리뷰가 걸린 저장소는 Approve 가 없으면 병합 버튼이 비활성화됩니다. 리뷰 요청을 먼저 보내고 기다립니다.

❌ 실수 2. Request changes 를 못 보고 지나침

변경 요구가 있으면 같은 리뷰어가 다시 승인하기 전까지 병합이 막힙니다. 반영 커밋을 올린 뒤 재검토를 요청합니다.

❌ 실수 3. CODEOWNERS 를 잘못된 위치에 둠

루트, .github/, docs/ 세 곳 중 하나가 아니면 GitHub 가 인식하지 않습니다. 저장소마다 한 곳만 고릅니다.

❌ 실수 4. CODEOWNERS 패턴 순서를 반대로 생각

먼저 쓴 패턴이 이긴다고 착각하기 쉽지만 나중(아래) 패턴이 우선합니다. 좁은 규칙은 파일 아래쪽에 둡니다.

❌ 실수 5. 필수 검사 실패를 무시

CI 가 빨간색이면 리뷰가 다 끝나도 병합이 막힙니다. 실패 로그부터 확인하고 다시 push 합니다.

❌ 실수 6. main 에 직접 force push 시도

보호 규칙이 걸린 브랜치는 --force 를 줘도 서버 훅이 거절합니다. 히스토리를 되돌리는 대신 새 커밋을 쌓습니다.

❌ 실수 7. force 와 force-with-lease 를 같은 것으로 취급

--force 는 원격 상태를 확인하지 않고 덮어써 동료 커밋을 지울 수 있습니다. 내 브랜치라도 --force-with-lease 를 기본으로 씁니다.

❌ 실수 8. squash 후 원본 커밋 로그를 찾음

squash 병합은 커밋을 하나로 합치므로 원래 커밋 여러 개는 이력에 남지 않습니다. 필요하면 PR 화면의 Commits 탭에서만 확인할 수 있습니다.

❌ 실수 9. --no-ff 없이 병합해 PR 경계가 사라짐

옵션 없이 git merge 만 쓰면 조건에 따라 fast-forward 로 합쳐져 병합 커밋이 남지 않습니다. PR 단위를 남기려면 --no-ff 를 명시합니다.

❌ 실수 10. 뒤처진 PR 을 그대로 병합 요청

base 가 오래된 채로 병합하면 예상 못 한 충돌이나 되돌림이 섞일 수 있습니다. rebase 나 merge 로 먼저 따라잡고 병합을 요청합니다.