1. Push하기
GitHub 리포지터리에 자료를 올리는 것을 Push라고 한다. 이는 Commit(커밋)과는 약간 다른 개념으로,
변경 사항을 (로컬) 리포지터리에 저장하는 것이 Commit
(로컬 리포지터리의) 변경 사항을 GitHub(공유) 리포지터리에 업로드하는 것이 Push다.
커밋할 땐 요약(Summary)과 설명(Description)을 잘 작성해, 다른 팀원들이 "어떤 사항이 변경됐는가?"를 쉽게 파악할 수 있게끔 해야 한다. 요약을 안 적으면 커밋이 활성화되지 않아 처음에 횟깔리지만. 요약이름이 분기점 이름이 되기 때문이다. 날자시간등으로 자동생성되지 않는다
언리얼 작업에서, 지금껏 작업한 내용을 커밋하는 방법엔 두 가지가 있다.
1-1. 언리얼 엔진에서 커밋하기
먼저, 언리얼 엔진 내부에서 직접 커밋할 수 있다.
지난 시간에 등록한 프로젝트다. 3인칭 기본 프로젝트로, 아직 아무 것도 건들지 않은 상태다.
먼저 가볍게 파란 큐브 하나를 지워주겠다. 물체를 지울 땐, 마우스로 클릭 후 Delete 키나 백스페이스 키를 누르면 삭제된다
변경 사항이 생겼으니 Ctrl + S를 눌러 저장해주자. 아이콘위 ?가 +로 바낀다
이제 변경 사항을 커밋해보자. 우측 하단의 리비전 컨트롤을 눌러주자.
제대로 저장했다면 '모두 저장됨'이 나타난다.
연동할 때와 달리 콘텐츠 제출이 활성화된 걸 볼 수 있다. 가볍게 클릭해주자.
이는 커밋할 내용을 찾고 있다는 뜻이다. 변경 사항이 적다면 순식간에 끝난다.
그리고 위와 같은 창이 뜬다. 내가 지운 큐브의 이름은 YFYBQ72OYLHJQS0TSSXGBV였다.
위엔 커밋 내용을 작성할 창이, 아래엔 커밋할 변경 사항(에셋)을 선택하는 창이 나타난다.
파일 체크아웃 유지는 커밋한 파일을 체크아웃 상태로 유지시키는 옵션이다. chatGPT에게 물어본 답변을 요약해보면, 내가 올린 파일들을 다른 사람이 직접 수정할 수 있게 만들어주는 옵션이다. 당연히 켜야할 것 같지만, 선택이 안 되니 그냥 넘어가자.
간단하게 커밋 내용을 작성하고 확인을 눌러봤다.
커밋 내용을 작성할 때, 엔터 키를 두 번 누르면 요약과 설명이 분리된다.
즉 "큐브 삭제"는 요약으로, "- 파란색 큐브를 삭제하였습니다." 설명에 자동으로 들어간다!
이는 VS code에서도 똑같이 동작하며, 꽤 편하다.
성공적으로 커밋됐다! GitHub Desktop을 열어 제대로 커밋됐는지 알아보자.
History에서 우리가 제출한 내용이 바로 반영된 것을 확인할 수 있다. 오른쪽 위에 Push origin 버튼이 활성화되고 1개가 적혀있는데, 이는 다른 커밋 방법을 알아본 후 눌러보겠다.
1-2. GitHub Desktop에서 커밋하기
다음으로, GitHub Desktop 앱에서 커밋할 수 있다.
큐브를 하나 더 삭제한 후 저장했다. 이번엔 바로 GitHub Desktop을 켜보겠다.
맨 위에 .uasset 하나가 -로 추가된 걸 볼 수 있다. 저 에셋이 바로 내가 삭제한 큐브다.
언리얼에서 커밋할 때와 달리, bin이나 json, ini 같은 파일들이 보인다. 대부분 작업 중 발생한 로그 파일이나 더미 파일이다.
우린 여기서 2가지 선택지를 갖는다. 내가 바꾼 에셋만 커밋하거나, 전부 다 커밋하거나.
변경 사항이 많을 수록 에셋 고르기가 어려워지니, 전부 다 커밋해보겠다.
GitHub Desktop은 요약과 설명 창이 따로 있는 게 편한 점이다.
작성을 완료했다면 Commit to KMC(자신의 브랜치)를 눌러주자.
변경사항들이 파란색에서 비활성화된다.
약간의 로딩 후, 모든 Changes가 사라진 것을 볼 수 있다. 그리고 Push origin은 2개로 늘어났다.
여기까지, 2가지 방법으로 2개의 커밋을 올려봤다. 하지만, 커밋은 어디까지나 내 컴퓨터 내에 저장하는 것이다.
GitHub 웹에서 살펴보면 아무 커밋도 추가되지 않았다.
이제 Push로 여기에도 올려보자.
(실수로 main 브랜치로 찍었는데, KMC 브랜치도 똑같다...)
방법은 허무할 정도로 간단한데, 그냥 아까부터 자길 눌러달라고 소리치는 Push origin을 눌러주면 끝이다.
그럼 자신의 브랜치에 변경 사항이 업로드된 걸 볼 수 있다.
2. Pull Request 등록하기 (Merge 하기)
당신은 열심히 작업하고 Push했지만, 팀원들은 여전히 "어디 두셨어요?"라고 물어볼 수도 있다.
이는 Push한 내용이 main 브랜치가 아닌 개인 브랜치(KMC)에 올라갔기 때문이다.
만약 당신이 작업한 내용이 아무런 문제가 없다면, 팀장에게 당당하게 "제 작업물 main에 합쳐주세요!"라고 말할 수 있다.
그럼 팀장은 말할 것이다. "PR 올려두면 머지해줄게."
PR은 또 뭐고, 머지는 또 뭘까?
PR은 Pull Request의 약자로, 직역(?)하면 Pull 요청쯤 될 것이다.
당신이 커밋한 후 GitHub 사이트로 접속하면, 위쪽 탭 중 Pull requests 탭을 찾을 수 있을 것이다.
또는 높은 확률로, 위 사진처럼 "올리세요!!!"하고 온몸으로 외치고 있을 것이다. (Compare & pull request)
Compare & pull request를 눌러보자.
그럼 커밋할 때와 비슷하게, 짧은 한 줄과 긴 여러 줄이 나타난다.
여기도 마찬가지로 제목에 간단한 요약을, 아래에 세부적인 작업 내용을 정리해서 작성하면 된다.
아래로 내려보면 지금껏 작업한 내용들이 시간 순으로 정리되어 있다.
적당히 설명을 써서 PR을 만들어보자.
이렇게 내용을 작성하고, Create pull request를 눌러주면 된다.
성공적으로 PR이 만들어졌다.
Merge pull request 버튼을 누르면 당신의 브랜치 커밋들이 main에도 적용된다. 보통 저 버튼은 팀장들에겐 활성화되고, 팀원들에겐 막혀있는 경우가 많다. main에 무분별하게 합쳐져 프로젝트가 고장나는 일을 방지하기 위해서다.
이렇게 올려둔 후 팀장에게 "PR 올렸어요"라고 말하면, 할 일 많은 팀장님이 안전한지 검사 후 머지시켜줄 것이다. 그리고 모든 팀원들에게 "main 브랜치 갱신되었으니, 다들 Pull 한 번씩 부탁드릴게요~~"라고 말할 것이다.
나는 Merge 권한이 있으니, 직접 머지시켜보겠다. 참고로 Merge 권한은 팀장이 원하는 인원에게 부여할 수도 있다.
Merge pull request 버튼을 누르면 위처럼 댓글을 쓰는 창이 나타난다. 익숙한 창...
Confirm merge를 눌러 통과시켜주자.
이로써 당신의 작업물은 무사히 프로젝트에 안착했다.
3. Pull 하기
열심히 일하던 제 3의 팀원은 청천벽력이었다. 갑자기 Pull 하라고? 그게 뭐지?
Pull은 프로젝트 내용을 갱신하는 것이다. main 브랜치에 변경 사항이 생겼고, 팀장이 안전성 테스트까지 끝마쳤으니 모두가 업데이트 된 버전의 프로젝트로 갱신하는 것이다.
다행히도 Pull은 정말... 너무나도... 허무할 정도로 쉽다.
3-1. GitHub Desktop에서 Pull 하기
변경 사항이 있다면, 위 사진처럼 Pull origin이라는 버튼이 활성화 된다. 저걸 눌러주면 끝이다.
만약 저 버튼이 없다면, 아래 방법으로 Pull이 가능하다.
메뉴 탭의 Repository를 눌러보면 Pull이 보일 것이다. 친절히 단축키까지 적어줬다. 눌러주자.
달라진 건 없어 보이겠지만, 제대로 Pull이 완료됐다. 언리얼로 돌아가면 변경 사항을 확인할 수 있을 것이다.
여기서 주의할 점은, 앱 위쪽에 Current branch가 보일 것이다. 이는 Push/Pull 할 브랜치를 지정하는 곳이다. 따라서 이걸 main으로 변경한 뒤 Pull을 해야 변경 사항이 당신의 컴퓨터에도 갱신된다.
'언리얼엔진/Github 깔기' Related Articles
'언리얼엔진 > Github 깔기' 카테고리의 다른 글
| 협업시 관리해야할 언리얼 엔진 4 디렉토리에 대하여 (0) | 2023.10.06 |
|---|---|
| 언리얼 깃허브 연동 2 - 팀원편 (1) | 2023.10.05 |
| 언리얼 깃허브 연동하기 팀장편 (2) | 2023.10.05 |
