[ 용어 정리 ]
Repository : 프로젝트를 저장하기 위한 저장소
Local Repository : 내 PC에서 관리하는 Git 저장소
Remote Repository : 서버나 네트워크에 있는 저장소 (ex : GitHub)
Init : 소스코드 파일을 Git으로 관리하기위해 Git 저장소를 초기화
( Init 전까지는 일반 폴더에 해당 )
Clone : Remote Repository를 Local Repository로 복사하여 내 PC에 새로운 저장소 생성
( GitHub 상 오픈소스 혹은 이미 만들어진 프로젝트 개발에 참여시 )
Branch : Git Repository 생성시 기본적으로 main branch가 생성되며,
Branch를 통해 여러 작업을 각자 독립적인 저장소에서 진행이 가능하다.
Commit : 프로젝트에서 수정한 사항 중 의미있는 변경 작업들을 Git Repository에 기록하는 동작
( Local Repository에는 반영 O, Remote Repository에는 아직 반영 X )
Push : Commit한 파일을 Remote Repository에 반영
Merge : 2개 이상의 Branch를 하나로 합치는 작업
Fetch : Local Repository에는 없지만 Remote Repository에는 반영된 데이터를 모두 가져옴
( Merge 되지 않으며, 변경 내용들을 확인만 하려고 할때 )
Pull : Local Repository에는 없지만 Remote Repository에는 반영된 데이터를 모두 가져와,
자동으로 현재 작업중인 Local Branch와 Merge
( 즉, Fetch + Merge )
[ Branch란? ]
Git Repository 생성시 기본적으로 main branch가 생성되며 main branch는 언제든지 배포/출시가 가능한 코드들만 올라와 있어야 한다. 따라서 main branch를 대상으로 하는 Commit, Push, Pull은 Repository 생성 후 프로젝트 초기 세팅을 제외한 경우에는 발생하지 않도록 주의해야한다.
간단한 개인 프로젝트는 main branch 위에서만 작업해도 충분하다. 하지만 협업 개발 프로젝트에서 모든 개발이 main branch 위에서 진행될 경우 같은 파일을 동시 수정, 다수의 사용자가 commit 시 문제가 발생할 수 있다. 이를 해결하기 위한 것이 Branch이다.
main branch를 나둔채로 최신 버전의 main branch에서 새로운 branch를 따 해당 branch에서 작업한 뒤 모든 검증이 완료된 후 main branch로 합치는 방식으로 작업을 진행한다.
branch를 나누는 기준은 작업자, 기능 추가, 버그 수정 등 다양하다.
작업한 branch를 main branch와 합치는 것을 merge라고 하며, merge 작업을 요청하는 것을 pull request 라고 한다.
[ 프로그램 정리 ]
GitHub Desktop : GitHub의 Repository를 Desktop에 다운받아 관리하는 것을 도와주는 프로그램
[ GitHub Desktop 사용 방법 ]
# Push 방법 - 처음 프로젝트 생성시
1. GitHub Desktop에서 [ Current repository ] - [ Add ] - [ Clone Repository ] 클릭 후 Repository 선택
2. GitHub Desktop에서 Show in Explorer 클릭
3. Unity에서 새로운 프로젝트 생성
4. Unity에서 Assets 폴더 [ 우클릭 ] - [ Show in Explorer ] 클릭
5. 2번을 통한 Local Repository 창에 4번을 통한 프로젝트의 내용물들을 복붙
6. GitHub Desktop에서 변경사항들에 대한 Summary, Description 작성 후 Commit to master 클릭
7. Commit to master 완료 후 Push origin 클릭
# Push 방법 - 새로운 branch 생성시
1. GitHub Desktop에서 [ Current repository ] 에서 Repository 선택
2. GitHub Desktop에서 [ Current branch ] 에서 Filter 입력창에 새로운 Branch 이름 작성 후 Create new branch 클릭
( GitHub Webpage와 다른 개발자에게도 새로 만든 Branch를 보여주기 위해서는 Publish branch 클릭 )
3. GitHub Desktop에서 Show in Explorer 클릭
4. Unity에서 Assets 폴더 [ 우클릭 ] - [ Show in Explorer ] 클릭
5. 3번을 통한 Local Repository 창에 4번을 통한 프로젝트의 내용물들을 복붙
6. GitHub Desktop에서 변경사항들에 대한 Summary, Description 작성 후 Commit to master 클릭
7. Commit to master 완료 후 Push origin 클릭
8. 해당 branch에서 작업한 내용을 main branch와 합치기 위해 Create Pull Request 클릭
# Pull 방법
1. GitHub Desktop에서 Fetch origin 클릭
( Pull로 가져올 변경사항의 유무를 알 수 있다. )
2. Pull origin 클릭
( 저장소에서 변경사항을 다운 )
[ GitHub Desktop 참고 사항 ]
1. 파란색 줄 표시 선택 및 해제를 통해 Commit 여부를 선택할 수 있다.
2. changed files에서 [ 오른쪽 마우스 ] - [ Discard all changes ] 를 통해 자신의 변경사항을 지우고 파일을 마지막으로 Commit한 상태로 되돌릴 수 있다.
( 2번은 파일단위로 Discard하는 것이고 1번처럼 줄단위로도 Discard가 가능)
3. 충돌 발생시 Merge 도구를 통해 수정한다.
[ Unity 프로젝트를 GitHub로 관리시 주의사항 ]
1. Unity 버전을 통일한다.
( meta 파일 내용이 버전에 따라 다르기 때문 )
2. Asset 직렬화 방식을 Binary가 아닌 Text로 통일한다.
( [ Edit ] - [ Project Settings ] - [ Editor ] - [ Asset Serialization ] 의 Mode를 Force Text로 변경 )
3. meta 파일의 생성/파괴 패턴 주의
( Unity는 meta 파일에 기록된 guid로 Scene에 포함된 Prefab, Prefab에 포함된 Model, Model이 사용하고 있는 Material, Material에 들어간 Texture등을 찾아내 서로 연결시켜준다. 따라서 meta 파일이 재생성되어 guid 값이 바뀌면 참조에 문제가 발생 )
( Editor가 아닌 탐색기에서 파일을 이동시키거나 이름을 변경한 경우, .meta 파일을 commit 하지 않고 push할 경우,
.meta 파일의 원본이 없는 경우에 meta 파일이 재생성 )
( 따라서 GitHub를 사용하지 않고 다른 개발자에게 파일을 보낼 경우 .meta 파일이 포함된 Unity Package로 파일을 전달 )
4. meta 파일의 갱신 주의
( 파일 Parameter가 변경된 경우 Save Project/Scene, Unity Editor 종료 시점 기준으로 meta 파일이 갱신 )
5. Git 서버에서 변경사항을 받아올때마다 meta 파일 갱신 주의
( [ Edit ] - [ Project Settings ] - [ Editor ] - [ Asset Serialization ] 에서 [ Version Control ] 과 [ Asset Serialization ] 을 통일하고 Unity Editor의 버전을 통일 )
( [ Version Control ] 은 Visible Meta Files를, [ Asset Serialization ] 은 Force Text를 권장 )