1. 오늘 한 것
스파르타 UE5 부트캠프의 Git 협업 기초 강의를 수강하며 GitHub 레포지토리를 직접 세팅하고, 팀원 상황을 로컬에서 시뮬레이션하여 fetch, pull, branch, merge, conflict 해결까지 전 과정을 실습하였습니다.
실습 레포지토리: https://github.com/taitop23-blip/TeamProject
GitHub - taitop23-blip/TeamProject
Contribute to taitop23-blip/TeamProject development by creating an account on GitHub.
github.com
2. 배운 내용
2.1 실습 환경 세팅
GitHub에 TeamProject 레포를 Public으로 생성하고, git clone으로 로컬 폴더를 만들었습니다. 이후 .gitignore와 .gitattributes 파일을 추가하고, UE5 프로젝트의 핵심 파일들만 로컬 레포 폴더로 이관하였습니다.
이관 대상 폴더/파일
Config폴더Content폴더Source폴더.uproject파일
나머지(Binaries, Intermediate 등)는 빌드 시 자동 생성되므로 .gitignore에 등록되어 있습니다.
.uproject 파일과 같은 폴더에 위치해야 합니다. 다른 위치에 두면 제대로 동작하지 않습니다..gitattributes는 .uasset, .umap 같은 바이너리 파일을 Git LFS로 추적하여 용량을 절약하기 위한 파일입니다. LFS 사용량은 GitHub Settings → Billing → Git LFS Data에서 확인할 수 있습니다. (기본 제공 1GB)
2.2 fetch vs pull
둘 다 리모트 레포지토리의 변경사항과 관련된 명령이지만 동작이 다릅니다.
- Fetch — 리모트를 '조회'만 합니다. 로컬에는 반영되지 않으며,
origin/main이main보다 앞서 있는 것을 확인할 수 있습니다. - Pull — 리모트의 변경사항을 실제로 내려받아 로컬 브랜치에 반영합니다.
2.3 branch & checkout
브랜치는 현재 프로젝트 기준으로 독립적인 작업 공간을 갖는 것입니다. 마블의 평행세계처럼 이해하면 쉽습니다. main 브랜치는 항상 깨끗한 세이브 포인트로 유지해야 하며, 직접 작업하지 않는 것을 권장합니다.
- 브랜치 이름 컨벤션:
Feature/기능명(예:Feature/Inventory,Feature/Rifle) - Checkout: 다른 브랜치로 이동하는 것. 이전 브랜치에 미커밋 변경사항이 없어야 합니다.
2.4 merge
Feature 브랜치에서 작업이 완료되면 main 브랜치에 합치는 과정입니다. 방향이 매우 중요합니다. main으로 체크아웃한 상태에서 Feature 브랜치를 우클릭하여 머지를 진행합니다.
main 브랜치로 체크아웃
→ Feature 브랜치 우클릭
→ "Merge Feature into current branch" 클릭
머지 전 체크리스트
- 빌드 및 게임플레이 정상 확인
- 언리얼 에디터 종료 후 소스트리 F5 새로고침
- 변경사항 꼼꼼히 읽기
- 머지 직전 반드시 Fetch / Pull 먼저 진행
2.5 conflict 해결
같은 파일을 두 사람이 동시에 수정했을 때 발생합니다. 소스트리에서 주황색 삼각형으로 표시된 파일이 충돌 파일입니다.
- 충돌 파일을 열면
<<<<<<< HEAD,=======,>>>>>>> 브랜치명으로 두 버전이 구분됩니다. - 팀원과 상의 후 합의한 내용으로 직접 수정합니다.
- 수정 후 파일 우클릭 → Resolve Conflicts → Mark Resolved
- 이후 커밋으로 마무리합니다.
// 충돌 마커 예시
<<<<<<< HEAD
UE_LOG(LogTemp, Warning, TEXT("AMyActor is ticking~~~"));
=======
//UE_LOG(LogTemp, Warning, TEXT("AMyActor is ticking!"));
>>>>>>> Refac3. 핵심 개념 요약
| 명령 / 기능 | 설명 | 소스트리 위치 |
|---|---|---|
Fetch |
리모트 변경사항을 조회만 함 (로컬 미반영) | 상단 Fetch 버튼 |
Pull |
리모트 변경사항을 로컬에 실제 반영 | 상단 Pull 버튼 |
Branch |
독립적인 작업 공간(평행세계) 생성 | Branch 버튼 |
Checkout |
다른 브랜치로 이동 | 브랜치 더블클릭 |
Merge |
브랜치 작업 내용을 현재 브랜치에 합침 | 브랜치 우클릭 → Merge |
Conflict |
같은 파일 동시 수정 시 발생, 수동 합의 필요 | 주황색 삼각형 파일 |
4. 느낀 점 & 회고
Git을 혼자 쓸 때는 add → commit → push 반복이었는데, 팀 협업 시뮬레이션을 직접 해보니 fetch와 merge의 타이밍이 생각보다 훨씬 중요하다는 것을 깨달았습니다.
특히 머지 전에는 반드시 Fetch/Pull을 먼저 해야 한다는 습관이 핵심인 것 같습니다. '선빵 당했을 때' 브랜치를 지우고 다시 만드는 방법도 처음엔 황당하게 느껴졌지만, 직접 해보니 오히려 명쾌한 해결법이었습니다.
충돌(conflict)도 처음에는 무섭게 보였는데, 마커(<<<<<<<, =======, >>>>>>>)의 의미를 이해하고 나면 그냥 '코드 합의'에 불과하다는 것을 알게 되었습니다.
5. 다음에 할 것
- 팀원과 함께 실제 충돌 상황 재현 및 해결 연습
- Git LFS 용량 관리 확인 (GitHub Settings → Billing → Git LFS Data)
- Pull Request 워크플로우 학습 (리뷰 기반 merge)