피처 브랜치 작업 시 무지개 머지를 피하는 법 🌈

Jayson·2025년 3월 28일

깃브랜치 터닝 협업

🧶 인트로: 작게, 안전하게, 그리고 리뷰 잘 받기 위한 노력

때는 바야흐로 5차 스프린트, 구현 단계에 접어들던 시점이었다.
이번엔 꼭! 코드리뷰를 잘 받고 싶었다.
그래서 리뷰어가 보기 좋은 PR을 만들기 위해 고민을 시작했다.

변경사항은 작게, 검증은 철저하게,
리뷰는 빠르게, 승인도 한 번에. 💪

이 목표를 이루기 위해 나는 PR을 최대한 작고 명확하게 나누기 시작했다.
그런데 이렇게 작업을 나누다 보니 자연스럽게 이전 작업을 기반으로 다음 작업을 이어가야 하는 경우가 자주 생겼다.

기존에 쓰던 Git 브랜치 전략으로는 걱정이 생겼다.

“이거... develop에 머지할 때 충돌 나면 어떡하지?” 😨
“그럼 그냥 이전 브랜치에서 다음 브랜치를 파면 되지 않을까?” 🤔
“맨 앞 피처가 머지되면 뒤에 딸린 꼬리들도 같이 머지되지 않을까?” 🧵

작은 단위로 PR을 만들어내다 보니 정말 예쁜 무지개를 만들었다? 🌈

🧨 그 무지개는 곧 코드 지옥의 문이었다.

🚨 피처 브랜치 작업 시 무지개 머지를 피하는 법 🌈

마지막 브랜치를 머지했는데, 뒤에 있는 꼬리 브랜치들의 변경사항이 develop에 반영되지 않았다.
그 결과 무지개 같은 머지 라인이 생겨버렸다.

문제 상황 예시

feat/1 ← from develop  
feat/2 ← from feat/1

머지 순서:

feat/1 → merge into develop  
feat/2 → merge into feat/1

❗ 문제점 1. develop에 머지되지 않는다

feat/2의 변경사항은 develop 브랜치에 머지되지 않아서, 최종 결과물에서 누락되는 문제가 생겼다.

❗ 문제점 2. 이전 변경사항까지 PR에 포함된다

feat/2의 PR에는 feat/1의 커밋이나 변경사항까지 함께 보여지게 된다.
리뷰어는 feat/2의 실제 변경 사항을 파악하기 어렵고, 앞 브랜치가 수정되면 뒤 브랜치도 영향을 받아 꼬일 수 있다.

🧪 과거 시도: before/after 전략

당시에는 이런 문제를 해결하기 위해 before, after라는 브랜치 관리 방식을 사용했다.

예를 들어, feat/1을 기반으로 feat/2를 만들고,
feat/2 브랜치를 feat/2-before로 리네이밍한 다음,
같은 위치에서 feat/2-after를 새로 만들어
feat/2-before의 내용을 병합하는 방식이었다.

이러면 feat/2-after만을 develop에 머지하면 되는 구조가 되긴 했다.

하지만 이 방식은 브랜치가 많아질수록 관리가 복잡해졌고,
모든 작업에 일일이 before/after 브랜치를 만드는 것은 유지보수 측면에서 비효율적이었다.

🧠 깨달음: rebase가 해결책이다!

이러한 문제를 고민하다가, 결국 해결 방법은 rebase에 있다는 걸 알게 되었다.

git checkout feat/2
git rebase develop

feat/2가 develop 브랜치의 최신 상태를 기준으로 다시 중차적으로 사이언스되며,
처음부터 develop에서 시작한 브랜치처럼 깔끔하게 정리된다.
그 덕분에 PR도 feat/2만의 변경사항만 보여줄 수 있고, 나중에 머지할 때 충돌 가능성도 줄어든다.

이전에는 before/after 브랜치를 만들어 수작업으로 커밋을 관리했지만,
rebase를 사용하면 훨씬 명확하고 체계적으로 커밋 히스토리를 관리할 수 있다.

작은 기능 브랜치들이 서로 독립적으로 리뷰 및 병합이 가능해지고,
PR 리뷰도 빨라지고 팀원 간 협업 효율도 훨씬 좋아졌다.

📂 깔끔한 PR을 위한 Git 작업 프로세스

# 1. develop 최신화
git checkout develop
git pull origin develop

# 2. feat/2 브랜치 생성
git checkout -b feat/2

# 3. 로컬에서 feat/1 병합 (push는 금지!)
git merge feat/1

# 4. PR 준비 작업 후 커밋
git add .
git commit -m "feat: feat/2 작업 기반 구현"

git push origin feat/2

feat/1이 머지되는 시점에서 feat/2 브랜치는 다음과 같이 정리하면 된다:

git checkout feat/2
git rebase develop

📝 PR 생성 시 주의사항

PR 대상은 develop
리뷰어에게 상황 설명 추가 권장

※ 이 브랜치는 feat/1을 기반으로 작업되었으며,
PR은 develop 기준입니다. feat/1이 먼저 머지되면 diff는 정리됩니다.

📌 핵심 요약

목표	방법
이전 피처 기반 작업	develop 기준으로 브랜치 생성
이전 코드 포함	로컬에서만 merge or rebase
깔끔한 PR 구성	PR 대상은 항상 develop, 리뷰 단위로 분리