[UE5 팀 프로젝트] Pull-Request 시행착오와 교훈

🎮 선택 의도

6인 팀 프로젝트의 코드 충돌을 예방하기 위해 '안전한' Fork-PR(Pull-Request) 전략을 채택했습니다.

 

선택한 워크플로우: Fork-PR

1. 각자 메인 저장소를 Fork
2. 개인 저장소에서 작업
3. 완료 후 Pull Request 생성
4. 리뷰어(관리자)가 코드 검토 후 Merge

 

 

 🚨 문제 상황

1. 관리자 병목 현상 초기 개발 단계에선 빠른 기능 추가가 필요한데, 관리자의 코드 리뷰가 '병목'이 되었습니다.

• Fork-PR: PR 생성 → 리뷰 대기 → Merge → 팀원 Pull
• 문제: 단순 Getter 함수 하나를 Merge하는 데 10분 이상 소요되어, 의존성이 있는 다른 팀원의 작업이 그대로 멈췄습니다.

2. 진짜 문제는 .uasset 충돌 정작 .cpp/.h 코드 충돌은 클래스 단위 작업 분리로 인해 거의 없었습니다. 진짜 문제는 바이너리 파일인 .uasset(블루프린트, 레벨) 충돌이었습니다.

• 치명적 한계: uasset은 텍스트가 아니라 리뷰(Review)가 불가능했습니다.
• 사고 발생: 충돌 시 Git은 자동 병합을 못하고 "내 것" 아니면 "상대 것"을 선택해야만 했습니다. 이 과정에서 한쪽의 작업물이 그대로 유실(lost)되는 사고가 발생했습니다.
• 결국, Fork-PR은 잡지도 못할 uasset 충돌을 예방하지도 못하면서, 코드 리뷰로 인한 속도 저하만 유발했습니다.

 

 

🔧 해결 및 교훈

1. 긴급 소통 채널 운영

• Discord에 "긴급 PR" 채널 생성
• 급한 PR은 여기 알림
• 관리자가 우선 처리

1. uasset 충돌은 Git 기능이 아닌, 사람 간의 '소통'으로 해결했습니다.

• 사전 공지: BP_Ingredient처럼 공용 블루프린트 수정 전, Discord에 미리 공지.
• 수동 병합: 충돌 시, 양쪽 작업자가 구두로 변경 사항을 확인한 뒤, 한 명이 수동으로 두 변경 사항을 모두 재적용했습니다.

2. 'git stash'의 발견 프로젝트 후반에 git stash라는 더 효율적인 방법을 알게 되었습니다.

# 현재 작업 임시 저장
git stash

# 최신 코드 가져오기
git pull origin main

# 작업 다시 꺼내기
git stash pop

# 충돌 나면 수동 해결

 

"이걸 일찍 알았더라면..."

 

 

Stash를 알았다면:

A: "기능 완료" → Push
B: 작업 중 → git stash → git pull → git stash pop
   → 충돌 있으면 해결 → 작업 계속

 

✅ 결과

 

워크플로우는 팀의 규모와 단계에 맞춰야 합니다.

 

Fork-PR은 코드 품질이 중요하고 리뷰 인력이 충분한 대규모/안정화 프로젝트에 적합합니다.

 

우리처럼 '빠른 프로토타이핑'이 중요한 소규모/초기 팀은, git stash 활용법을 익히고 '작업 전 소통'을 강화하는 Direct Push 방식이 훨씬 효율적이었을 것이라는 교훈을 얻었습니다.