nika-blog

PR 분할 전략과 git 머지 플로우 본문

카테고리 없음

PR 분할 전략과 git 머지 플로우

nika0 2025. 11. 21. 17:18

안녕하세요.
IT 연합 동아리 디프만 17기 4팀 Web 파트장 이성현입니다.

 

저희 팀은 이번 디프만 활동을 통해 배변 기록을 기반으로 장 건강을 관리하는 서비스 kkruk(꾸룩)을 개발했습니다.

(iOS 앱 출시 완료 🎉)

저는 이번 프로젝트에서 React Native 기반 App 파트와 Next.js 기반 Web 파트를 모두 담당하며 개발을 진행했으며, 파트장으로서 팀 운영과 기술 방향 설정도 함께 맡았습니다.

 

5년 차 개발자로서, 대부분 취업을 준비 중인 팀원들과 함께 프로젝트를 진행하면서 어떻게 하면 실무에 바로 도움이 되는 경험을 줄 수 있을까?를 가장 중요한 목표로 두었습니다.

그중에서도 특별히 강조했던 부분이 코드 리뷰 문화와 PR 분할 전략입니다.


이 두 가지는 신입·경력과 관계없이 많은 개발자들이 어려움을 겪는 영역이며, 제대로 익혀 두면 협업 효율과 코드 품질 모두 크게 향상됩니다. 저 역시 신입 시절 가장 힘들었던 부분이라 이번 프로젝트에서 꼭 체득할 수 있도록 돕고 싶었습니다.

 

그래서 팀 전체가 실무 수준의 개발 문화를 경험할 수 있도록, 프로젝트 전반에 걸쳐 코드 리뷰 프로세스와 PR 전략을 적극적으로 도입하고 실천했습니다. 이번 포스팅에서는 디프만 활동을 하며 고민했던 과정, 팀에 기여한 방식, 그리고 실제 현업에서도 바로 적용 가능한 코드 리뷰 및 PR 전략에 대해 정리해 보려고 합니다.

PR 분할 전략과 git 머지 플로우

코드 리뷰 피로도를 낮추고, 안정적인 개발 프로세스를 만들기 위한 가이드

개요

팀 내에서 개발 작업을 진행할 때 PR(Pull Request)을 최소 의미 단위로 분리하는 방식은 생산성과 코드 품질을 높이는 데 큰 도움이 됩니다.

 

다만 실제 협업 과정에서는 PR 간 의존성(dependency)이 발생하는 경우가 많고, 이로 인해 diff가 복잡해지거나 리뷰가 어려워지며, 머지 과정에서 충돌이 발생하는 등의 문제가 생기기도 합니다. 이번 글에서는 이러한 상황을 해결하기 위해 다음과 같은 내용을 정리해 보았습니다.

 

  • PR을 어떻게 적절한 단위로 분리해야 하는지
  • 종속 PR이 있을 때 머지 순서와 관리 방법
  • cherry-pick을 활용한 안전한 머지 전략
  • 효율적인 코드 리뷰 문화와 리뷰어를 배려하는 방법

목표

  • 리뷰어의 피로도 최소화
  • 대규모 PR에서 놓칠 수 있는 부분을 최소화
  • 깔끔한 Git 기록 유지
  • 팀 차원의 안정적인 협업 구조 마련

PR 분할 규칙

1. PR 단위

PR은 “최소한의 의미 단위”로 분할한다.

예시:

  • dependency 설치 → 별도 PR
  • 소규모 subtask → 별도 PR
  • 리팩토링 → 기능 PR과 분리
  • 공통 컴포넌트 도입 → 별도 PR

2. 변경 파일 수

  • 5개 이하 권장
  • 단, 이미지 등 static asset은 제외

3. diff 라인 수

  • 300줄 이하 권장

4. PR 관리

  • github milestone 활용
  • 순서가 있는 종속 PR들은 milestone을 통해 묶어서 관리
  • 예: 회원가입 기능 PR 묶음 (a → b → c)

종속 PR이 있을 때 발생하는 문제

예를 들어, PR들이 아래와 같이 종속되어 있다고 가정해 보겠습니다.

main → feature/a → feature/b → feature/c

 

이런 방식으로 종속되어 있을 때,
앞선 PR(a)이 squash merge되면 뒤 PR들은 기준 브랜치(main)가 변경되며 다음 문제가 발생합니다.

  • 뒤 PR들의 file-change diff가 깨짐
  • 원래 없던 diff가 섞여 리뷰가 어려워짐
  • rebase 반복 발생
  • 충돌 가능성 증가

해결 전략: Rebase 최소화 + Cherry-pick 기반 갱신

앞 PR이 merge되면, 다음 PR은 최신 main에서 PR 의 브랜치를 다시 만들고 cherry-pick만 한다

 

PR 의존 관계 & 머지 흐름

머지/갱신 과정 흐름도

 

  • PR A 머지
    개발자가 PR A를 main 브랜치에 머지합니다.
  • PR B 준비
    • 개발자는 main 브랜치를 최신 상태로 가져옵니다(git fetch main).
    • 그 후, 새 브랜치 B를 생성합니다.
    • B 브랜치에서 PR B의 커밋을 cherry-pick으로 가져옵니다.
    • 이후 B 브랜치를 강제 푸시(force push)하여 원격 저장소에 업데이트하고, PR B를 머지합니다.
  • PR C 준비
    • 개발자는 다시 main 브랜치를 최신 상태로 가져옵니다.
    • 새 브랜치 C를 생성하고, PR C의 커밋을 cherry-pick으로 가져옵니다.
    • C 브랜치를 원격 저장소에 강제 푸시하고, PR C를 머지합니다.
  • 모든 PR 머지 완료
    이렇게 하면, 의존성이 있는 PR들(A → B → C)도 순차적으로 안전하게 머지할 수 있으며, 각 PR의 diff가 깨지지 않고 리뷰가 용이해집니다.

 

 

Cherry-pick 기반 병합 순서

1. pr A 머지

2. 최신 main fetch

git fetch origin

3. pr B 재생성

git branch -D feature/b
git checkout -b feature/b origin/main
git cherry-pick <b-commit-hash>
git push -f origin feature/b

4. pr B 머지

5. pr C 동일 방식 반복

git fetch origin
git branch -D feature/c
git checkout -b feature/c origin/main
git cherry-pick <c-commit-hash>
git push -f origin feature/c

장점

  • 각 브랜치에서 rebase는 최소화
  • 충돌 가능성이 크게 감소
  • 커밋 기록이 깨끗하게 유지됨 (불필요한 merge commit 없음)
  • 리뷰어가 diff 흐름을 정확하게 파악 가능

이슈: 같은 이름의 브랜치 재생성 필요

cherry-pick 전략을 쓰면 브랜치를 다시 만들어야 하므로 아래 명령이 필수:

git branch -D feature/b
git checkout -b feature/b origin/main

최종 전략: 의존성 PR은 한 번에 머지하기

  • 리뷰는 미리 받아 놓고
  • 일괄 cherry-pick → 일괄 머지
  • main의 변동을 최소화하여 전체 병합 비용 절감

효과:

  • 리뷰어는 안정된 diff 기반으로 리뷰
  • 작성자는 cherry-pick/rebase를 1회만 수행
  • PR이 꼬이는 상황 자체가 거의 사라짐

코드 리뷰 문화 & 리뷰어 배려 가이드

기술적인 규칙만 잘 지킨다고 해서 협업이 완벽하게 이루어지는 것은 아닙니다. 실제로는 리뷰 문화가 프로젝트의 품질과 팀의 생산성에 큰 영향을 미치게 됩니다. 아래는 제가 팀에서 효과적으로 운영하고 있는 리뷰 문화의 주요 방식입니다.

1. 리뷰어 피로도를 최소화하자

리뷰어는 업무 중간에 시간을 쪼개서 리뷰를 진행합니다.
따라서 다음 원칙이 중요합니다.

  • PR은 가능한 작게
  • 변경 의도를 명확하게
  • 리뷰 포인트는 PR 설명에 미리 적기
  • 불필요한 파일(포맷팅/주석 삭제)은 분리 PR로 따로 올리기

2. 리뷰어에게 “생각해야 하는 일”을 넘기지 않기

리뷰어가 다음과 같은 질문을 하지 않아도 되도록:

  • “왜 이렇게 구현했지?”
  • “이 함수는 어디서 쓰지?”
  • “이게 이전 PR에서 온 건가?”

작성자가 미리 다음을 채워주면 됩니다.

  • 배경 설명
  • 결정한 이유(why)
  • 기존 코드와의 차이
  • 테스트 방법

3. 리뷰어에게 불필요하게 무례한 상황 만들지 않기

  • “빠른 리뷰 부탁드립니다!” 같은 압박 문구는 자제
  • “여유 있을 때 부탁드립니다” 또는 “시간 편할 때 한 번만 봐주세요!”
  • 리뷰를 반영할 때는 “반영했습니다!” 보다
    → “남겨주신 포인트 중 A, B는 반영했고 C는 이런 이유로 유지했습니다.”라고 컨텍스트 제공

4. 리뷰는 “태클”이 아니라 “협업”

  • 스타일 차이는 비난하지 말고, 팀 컨벤션으로 통일
  • 개인 취향(PR 선호 방식 등)은 팀 논의로 맞춤
  • 리뷰는 궁극적으로 코드를 통해 팀의 미래 시간을 절약하는 과정입니다.

5. 신속한 리뷰 중요성

PR이 오래 방치되면 다음 문제가 생깁니다.

  • merge conflict 증가
  • 작업 context 잊어버림
  • 팀 속도 저하

가능하면

  • “소규모 PR은 24시간 이내 리뷰”
  • “핵심 기능 PR은 48시간 이내 리뷰”

같은 기준을 팀에서 정하는 것이 좋습니다.

마무리

효율적인 PR 분할과 cherry-pick 기반 머지 전략은 팀의 개발 속도, 리뷰 품질, 그리고 코드 안정성을 모두 크게 향상시킵니다.

여기에 좋은 리뷰 문화까지 더해진다면, 협업 환경이 자연스럽게 건강해지고 팀의 생산성 또한 눈에 띄게 개선될 것입니다. 

 

디프만 활동을 하면서 좋은 팀원들을 만나, 타이트한 일정에도 즐겁게 개발했습니다. 앞으로도 좋은 인연을 유지해나가면서 또 함께 서비스를 개발할 기회가 있었으면 좋겠습니다. 감사합니다. 

 

앱을 개발하면서 디자이너분들도 많이 노력해주셨는데요, 귀여운 캐릭터도 함께 첨부해 봅니다 ㅎㅎ