StrikForge 11일차 - 트러블슈팅

트러블슈팅: 기존 작업 브랜치의 심각한 PR 충돌 해결

문제 상황

기존 작업 브랜치에서 PR을 진행하는 과정에서 다수의 충돌이 발생했다.

특히 다른 팀원의 브랜치에서는 문제가 발생하지 않았지만, 본인의 작업 브랜치에서만 충돌이 집중적으로 발생했다.

기존 작업 브랜치
→ develop 병합 시 다수의 충돌 발생
→ PR에 예상하지 못한 변경사항 포함

단순히 충돌 파일 몇 개를 수정하는 수준이 아니라, 그대로 Push 및 PR을 진행하면 다른 팀원이 작업한 내용이 사라지거나 과거 버전으로 되돌아갈 가능성이 있는 상황이었다.

문제의 영향

충돌 상태를 제대로 확인하지 않고 PR을 계속 진행할 경우 다음 문제가 예상됐다.

• 다른 팀원의 최신 코드 삭제
• 병합된 기능이 이전 코드로 덮어써짐
• 이미 이동된 파일이 다시 생성됨
• 최신 폴더 구조가 과거 구조로 되돌아감
• PR에 본인이 수정하지 않은 파일까지 포함
• 팀 전체 develop 브랜치에 잘못된 변경사항 반영

따라서 기존 브랜치에서 바로 충돌을 해결하거나 강제로 Push하지 않고 PR 진행을 일시적으로 중단했다.

초기 대응

관련된 팀원 3명이 아침에 모여 충돌 원인을 확인하고 해결 방법을 논의했다.

처음에는 다음 항목들이 복잡하게 얽혀 있어 해결 방향을 정하기 어려웠다.

• 기존 브랜치의 작업 이력
• 최신 develop과의 차이
• 병합 과정에서 발생한 충돌
• 다른 팀원 파일이 삭제 대상으로 표시되는 현상
• 어떤 변경사항을 유지해야 하는지 판단하기 어려운 상태

특히 충돌 표시만 해결하면 PR이 가능해지는 것이 아니라, 병합 결과에서 다른 팀원의 작업까지 정상적으로 유지되는지 확인해야 했다.

원인 판단

정확한 단일 원인을 확정하지는 못했지만, 기존 로컬 브랜치의 이력과 최신 develop의 변경 이력이 크게 달라진 상태에서 병합이 반복되면서 문제가 발생한 것으로 판단했다.

기존 로컬 브랜치의 작업 이력
+
최신 develop의 대규모 변경
+
기존 병합 및 충돌 기록
→ PR 변경 범위 비정상 확장

이 상태에서 기존 브랜치를 계속 복구하는 것보다 최신 develop을 기준으로 작업 브랜치를 다시 구성하는 것이 더 안전하다고 판단했다.

해결 과정

1. 기존 PR 중단

다른 팀원의 작업이 사라질 가능성을 확인한 뒤 PR 진행을 즉시 중단했다.

강제 Push나 임의의 충돌 해결은 진행하지 않았다.

2. 새로운 작업 브랜치 생성

기존 브랜치를 계속 사용하는 대신 새로운 작업 브랜치를 생성했다.

새 브랜치는 최신 develop을 기준으로 연결해 기존 브랜치에 남아 있던 잘못된 병합 상태의 영향을 받지 않도록 했다.

3. 기존 로컬 작업 환경 정리

기존 작업 환경에 남아 있던 브랜치와 병합 기록의 영향을 피하기 위해 새로운 Git Clone을 만들었다.

기존 로컬 저장소에서 계속 수정
→ 병합 기록과 충돌 상태가 남을 가능성

새로운 Clone
→ 원격 저장소의 정상 상태에서 다시 시작

4. 새로운 브랜치 Tracking

새로 Clone한 저장소에서 새 작업 브랜치를 Tracking하도록 설정했다.

원격 새 브랜치
→ 로컬 새 브랜치 Tracking
→ 최신 develop 기준 확인

5. develop 병합

새 브랜치에 최신 develop을 병합했다.

이 과정에서 기존 브랜치에서 발생했던 비정상적인 대규모 삭제나 충돌이 다시 나타나는지 확인했다.

6. Push 및 전체 변경사항 확인

병합 결과를 Push한 뒤 다음 내용을 확인했다.

• 다른 팀원의 코드가 유지되는지
• 본인이 작성한 코드가 유지되는지
• 파일 경로가 최신 구조와 일치하는지
• 예상하지 못한 삭제 파일이 없는지
• PR 변경 내역에 불필요한 파일이 포함되지 않았는지
• develop의 최신 기능이 유지되는지

확인 결과 새로운 브랜치에서는 문제가 발생하지 않았다.

7. 기존 브랜치 삭제

새 브랜치의 병합 및 Push 결과에 문제가 없음을 확인한 뒤, 충돌 문제가 발생했던 기존 브랜치를 삭제했다.

이를 통해 이후 실수로 기존 브랜치에서 다시 작업하거나 PR을 생성하는 상황을 방지했다.

해결 결과

새로운 Clone과 최신 develop 기반의 새 브랜치를 사용하면서 충돌 문제를 해결했다.

최종적으로 다음 상태를 확인했다.

다른 팀원의 최신 작업 유지
본인의 GameMode/GameState 작업 유지
최신 폴더 구조 유지
불필요한 삭제 파일 없음
새 브랜치 Push 정상
PR 변경 범위 정상

기존 문제가 있던 브랜치는 제거했고, 새 브랜치에서 정상적으로 작업을 이어갈 수 있게 됐다.

잘한 대응

이번 문제에서 가장 중요한 대응은 다른 팀원의 작업이 사라질 가능성을 확인한 순간 PR을 중단한 것이다.

충돌을 빠르게 끝내기 위해 임의로 다음 작업을 진행했다면 문제가 커질 수 있었다.

강제 Push
무조건 현재 브랜치 내용 선택
충돌 파일 전체 덮어쓰기
최신 develop 변경 제거

대신 새 Clone과 새 브랜치를 이용해 원격의 정상 상태를 기준으로 작업을 복구했다.

배운 점

PR의 충돌 해결만으로 끝내지 않아야 한다

충돌 표시가 사라졌다고 해서 병합 결과가 정상이라는 의미는 아니다.

반드시 다음을 확인해야 한다.

• 삭제된 파일
• 변경된 파일 수
• 본인이 수정하지 않은 파일
• 다른 팀원의 최신 코드
• 폴더 이동 및 파일명 변경
• PR 전체 Diff

충돌이 심하면 새 기준점에서 재구성하는 것이 안전할 수 있다

기존 브랜치의 병합 이력이 복잡하고 변경 범위가 비정상적이라면, 충돌을 하나씩 해결하는 것보다 최신 develop에서 새 브랜치를 만드는 것이 더 안전할 수 있다.

Push 전에 팀원 작업 보존 여부를 확인해야 한다

본인의 코드가 정상인지 확인하는 것만으로는 부족하다. 협업 프로젝트에서는 다른 팀원의 코드가 삭제되거나 과거 상태로 돌아가지 않는지도 확인해야 한다.

문제 브랜치는 즉시 삭제하지 않는다

새 브랜치의 작업과 Push 결과를 확인하기 전까지 기존 브랜치를 보관해 복구 가능성을 유지했다. 새 브랜치가 정상임을 확인한 후 기존 브랜치를 삭제했다.

향후 예방 방법

앞으로 PR과 병합 전에 다음 순서로 확인한다.

1. 작업 내용 Commit
2. 원격 최신 정보 Fetch
3. develop 변경사항 확인
4. 작업 브랜치에 develop 병합
5. 충돌 파일 해결
6. 전체 Git Diff 확인
7. 예상하지 못한 삭제 확인
8. 다른 담당자 파일 변경 여부 확인
9. 테스트 후 Push
10. PR의 Files Changed 최종 확인

충돌 범위가 비정상적으로 크다면 바로 Push하지 않고 팀원과 확인한 뒤, 필요할 경우 최신 develop 기반의 새 브랜치와 새 Clone을 사용하는 방식으로 대응한다.