병합 충돌 해결
프로젝트 개별 개발이 끝나고 이제 병합을 할 차례가 왔는데 역시나 문제가 발생했습니다.
발생한 이슈는 크게는 아래와 같았습니다
- 씬 수정으로 인한 충돌
- 중복 파일로 인한 충돌
- 잘못된 dev 브랜치 위치로 인한 충돌
위의 문제들을 발견하면서 확인했던 가장 큰 문제점은 역시 main -> Dev(Merge) 브랜치를 생성할때 실수를 했다는 점에 있었습니다.
- 우선, main 에서 유니티 프로젝트를 생성시, 아예 씬 자체를 비워두었어야 하는데 그러지 않았고
- 다음으로는 Dev 브랜치의 하위 브랜츠로 작업 브랜치를 설정했어야 하는데 Dev와 형제 관계로 개발 브랜치가 생성되었습니다.
최초의 브랜치 생성시에 발생했던 문제였기 때문에, 충돌을 피하기 위해 프로젝트 세팅을 변경하거나, 정 안되는 경우 package 추출을 통해서 삽입해 주어야 했습니다.
더 조사해본 내용은 아래와 같았습니다
Git Branch 전략 및 Merge 컨벤션
📌 브랜치 구조
main
└─ dev
└─ feature/<기능명>1. main 브랜치
- 배포용 브랜치
- 항상 안정된 코드만 존재해야 함
- 실제 서비스에 반영되는 코드 기준
2. dev 브랜치
- 개발 통합 브랜치
- 여러 기능(feature) 브랜치에서 머지된 작업물들이 모이는 곳
- QA 또는 사내 테스트 용도의 브랜치
- 일정 주기로 main 브랜치에 머지
3. feature 브랜치
- 개별 기능 개발을 위한 브랜치
- dev 브랜치에서 분기
- 기능 단위로 생성:
feature/login,feature/user-profile등 - 작업 완료 후 dev 브랜치에 Pull Request
🔁 Merge 전략
| 머지 대상 | 전략 | 설명 |
|---|---|---|
| feature → dev | Squash Merge | 커밋 이력을 하나로 합쳐 dev에 머지 |
| dev → main | Merge Commit | 전체 히스토리를 유지하며 main에 머지 |
🎯 Squash Merge (기능 개발 머지 시)
- 커밋 정리가 용이하며, dev 브랜치에 깔끔한 히스토리 유지
- PR 제목이 최종 커밋 메시지가 됨
🎯 Merge Commit (배포 시)
- dev 브랜치의 전체 커밋 히스토리를 유지
- 배포 단위로 커밋 구간을 명확하게 식별 가능
시연 영상 및 발표자료, 빌드 파일 링크
클라이언트 개발자를 지망하고 있습니다.