[git] 내가 올린 PR(Pull Request) 이 마음에 들지 않는다.

들어가기 전

개발을 하다 보면 협업 과정에서 깃(Git)을 기반으로 한 다양한 도구를 사용하게 됩니다.
대표적으로 GitHub, GitLab, Bitbucket 같은 플랫폼이 있습니다.

 

이번 글에서는 그중에서도 GitHub에서 ‘좋은 PR(Pull Request)’을 올리는 방법에 대해
제가 느낀 점과 경험을 바탕으로 정리해보려 합니다.

 

최근 팀에서 SVN을 벗어나 GitHub로 형상 관리를 옮기면서
처음으로 PR을 자주 올리게 됐습니다.
그런데 막상 올리고 나니, 제가 올린 PR이 뭔가 마음에 들지 않더라고요.

 

그 일을 계기로 “도대체 좋은 PR은 어떤 걸까?”를 고민하게 되었고,
그 고민을 정리하는 의미로 이 글을 쓰게 되었습니다.

 

사실 개발을 처음 시작했을 때도 비슷한 경험이 있었어요.
그때 멘토분이 해주신 조언과, 이후 여러 협업을 하면서 직접 느낀 부분들을
이번 글에서 차근히 풀어보려 합니다.

 

본격적으로 시작하기 전에, 간단하게 PR이 뭔지부터 정리하고 가겠습니다.

---

Pull Request란?

Pull Request(PR) 는 협업 중인 개발자가 자신이 작업한 내용을
다른 사람에게 리뷰받고, 메인 브랜치에 병합(merge)해달라고 요청하는 절차를 말합니다.

쉽게 말해,

“제가 이 기능을 이렇게 구현했는데, 한 번 확인하고 합쳐주세요!”

 

라는 의미의 요청이에요.

 

PR은 단순히 코드를 합치는 과정이 아니라,
팀원들이 서로의 코드를 리뷰하고 의견을 주고받는 소통의 공간?이기도 합니다.

덕분에 코드 품질을 높이고, 프로젝트의 일관성을 유지할 수 있습니다.

---

어떤 PR이 좋은 PR일까?

리뷰는 ‘요구’가 아니라 ‘요청’이다

PR을 올린다는 건 리뷰어에게 “코드를 봐주세요!” 하고 요청하는 거예요.
즉, 리뷰어가 자신의 시간을 내어 내 코드를 봐주는 거죠.

 

그래서 저는 PR을 올릴 때 “내가 보기 편한 코드?”라기 보다는 보기 좋은 단위로 올려
리뷰어가 보기 PR을 만드는 게 더 중요하다고 생각합니다.

 

---

PR의 규모는 ‘적당한 게 좋다’

최근 A라는 기능을 개발하다 보니,
생각지도 못하게 B와 C 기능까지 손을 대야 하는 상황이 생겼습니다.

결국 리팩토링까지 이어지면서 PR이 꽤 커졌고,
리뷰어 입장에서 “이건 좀 너무 많다…” 싶을 정도의 변경량이 되어버렸죠.

그때 예전에 멘토가 해줬던 말이 떠올랐습니다.

“커밋을 자주 하라.”

 

처음엔 “그냥 자주 저장하라는 뜻인가?” 했는데,
사실 그 말의 의미는 성격이 다른 변경을 나누어 커밋하라는 뜻이었습니다.

 

커밋을 나누라는 말은 목차를 나눠라? 라고 비슷한 의미라고 생각하게 되었습니다.

 

 

기능을 개발하다 보면 여러 가지 변경이 한꺼번에 일어납니다.
그럴 때는 이렇게 구분해두면 좋을거 같아 저의 생각을 작성해봅니다.

• 기능 단위로 커밋
• 혹은 Entity, Repository, Service, Controller 같은 레이어 단위로 커밋
• A 기능을 개발하다가 다른 부분을 수정하게 됐다면, 커밋 메시지로 의도를 명확히 표시
  예를 들어 ,
  • fix: A 기능 개발 중 발생한 오류 수정
  • refactor: 중복 제거 및 메서드 구조 개선
  • bug: A 기능 개발 중 발견된 B 기능의 버그 수정

이렇게 커밋을 논리적으로 나누면
리뷰어도 “이 부분은 이런 이유로 수정됐구나” 하고 쉽게 이해할 수 있습니다.

 

결국 커밋 단위에는 정답이 없지만,
리뷰하기 좋은 단위로 쪼개는 습관이 정말 중요하다고 느꼈어요.

 

---

PR 문서는 자세할수록 좋다

PR 설명은 리뷰어와의 대화 공간이라고 생각합니다.

“이 PR에서 무슨 변경이 있었는지”,
“왜 이렇게 수정했는지”,
“어떤 부분을 특히 봐주면 좋은지”
이 세 가지는 꼭 명시하는게 좋다라고 생각하게 되더라고요.

 

물론 막상 PR 문서를 써보면 이게 제일 어렵더라고요.
“이 정도면 충분할까?” 싶은 생각이 계속 들거든요.

 

그래서 저는 요즘 노션(Notion) 을 활용해서
개발 과정에서 고민했던 부분이나 의사결정 과정을 정리해두고,
그 링크를 PR에 첨부하는 방식을 시도하고 있습니다.

 

이렇게 하면 리뷰어가 단순히 코드만 보는 게 아니라
왜 이런 구조가 되었는지의 배경까지 함께 볼 수 있어서 훨씬 좋더라고요.

 

또 하나는, PR 템플릿을 팀 내에서 공유해두는면 어떨까? 라는 생각을 하고 있습니다.
Issue는 지금 템플릿을 만들어서 작성하면 좋을거 같아 만들어 둔 상태인데요.

 

PR도 일정한 형식을 맞춰두면, 모두가 비슷한 구조로 작성할 수 있어서 리뷰가 훨씬 빨라질거라 생각하고 있습니다.

 

근데 막상 적어보니 너무 자세하면 피로할거 같기도하고...

---

마무리

아직 GitHub 협업 경험이 많다고는 할 수 없지만,
이번 일을 계기로 PR을 더 자주 올리고, 리뷰를 통해 성장하자는 다짐을 하게 됐습니다.

 

결국 좋은 PR은 기술적인 완성도만큼이나 “함께 일하기 좋은 태도”에서 나온다는 생각이 들어요.

(짤은 그냥 그냥 웃겨서 가져와 봤습니다)

 

이번 글은 기술 팁보다는,
좋은 협업을 위한 생각에 대한 글이었습니다.

 

읽어주셔서 감사합니다!!