[번역] 팀 개발에서의 Git 운용 예. 언리얼 엔진

역자의 말.

뭐 사실 직접 기사를 쓰지 않고 번역글(변환글?)만 포스팅으로 채우는게 아닌가 싶기도 하지만... ㅎㅎ 목적이 테크아트노마드 블로그 가면 도움되는 기사 아카이브 같은 곳이라고 생각이 들어야한다는 게 목적이고 따로 포럼을 만들지 않아서... 당분간은 의래 하던대로 번역기사 위주로 가겠습니다. ㅎㅎㅎ. 테크아트닷아이오 웹사이트를 만들고 있지만 아직도 여전히 공사중이고 컨설팅 일도 2개를 동시에 진행하고 있다보니 여유시간이 많이 나질 않네요. 그래도 언리얼 엔진 관련 해서 독자적인 기사도 준비는 할 예정입니다. 유니티도요. 주로 GPU DRIVEN 에 관련 된 것들이 되겠네요. 아무튼... 아티스트들이 Git 에 잘 적응을 못하는 경향? 이 있다고 해서 일본분의 기사글을 간접포스트팅 해 봤습니다.

---

필자: Pate

https://twitter.com/mx_pate4

X의 pate님(@mx_pate4)

소개

 

저희 회사에서는 소스 제어 도구로 Perforce를 사용하고 있었습니다.
Perforce로 소스를 관리하면서 하나의 프로젝트 버전 1.0.0을 릴리즈할 때까지 왔지만, 릴리즈한 시점에 Git으로 전환을 시작하게 되었습니다.
Perforce를 그만둔 이유는 무엇인가요?

• 문서가 적다
• 무료 범위에서 사용하다가 규모가 커지면 비용이 감당할 수 없을 정도로 커진다.
• Depot이 그저 프로젝트 백업처럼 사용하게 되었다.
• 워크플로우를 최적화할 수 없었다(이는 전적으로 내 잘못이지만, 문서가 적고 커뮤니티의 규모와도 관련이 있을 것 같다)

이것이 전환하게 된 가장 큰 이유입니다.
저희 회사에는 인턴십 멤버도 있는데, 교육의 일환으로 '커리어 형성 차원에서 Git 사용법을 알아두는 것이 좋지 않을까'라는 생각이 머릿속 한구석에 자리 잡고 있었던 것도 한 요인입니다.

팀에서 Git을 사용한 지 3개월 정도 지났는데, Git 커뮤니티의 규모와 논리적인 워크플로우를 기반으로 한 강력한 개발 환경을 접하면서 Git의 강력함을 다시 한 번 실감했습니다.

워크플로우에 대하여

다양한 문헌을 찾아보고 나름대로 워크플로우를 최적화한 결과, 한동안은 지금의 운영으로 문제없이 개발을 진행하고 있습니다.
하지만 실제로 UE에서 어떤 식으로 Git을 운용하고 있는지에 대한 글은 찾아보기 힘들었고, Git 전환 직후의 초보인 저에겐 장벽이 높았습니다.
앞으로 UE × Git을 사용하는 사람들이 많아져서 좀 더 구체적인 운영 사례를 보여줄 수 있으면 좋겠다는 생각이 듭니다.

다만, 이번에 소개하는 당사의 Git 운용법은 Git을 접한 지 3개월 된 초보자가 생각한 한 가지 예시이니, 참고 정도로만 봐주시면 감사하겠습니다.

환경 개요

각 도구에 대해 차례로 설명하겠습니다.

주로 태스크의 1차 접수처로 사용하고 있습니다.
회사 사정상 어쩔 수 없이 Notion을 개입시켜야 하기 때문에 이슈에 작성할 정도는 아닌 간단한 자기 메모적인 역할과 이슈를 생성하기 위한 1차 수신기로 사용하고 있습니다.
특별한 이유가 없다면 Github의 Projects 기능으로 충분하다고 생각합니다.

저는 이슈와 풀 리퀘스트를 생성하고 리뷰를 주고받습니다.
Github은 아직 익숙하지 않은 것 같아서 기능을 좀 더 살펴보고 싶어요.
깃허브보다 더 좋은 서비스가 있을지도 모르니까요.
지금은 사용하고 있습니다.

이 기능이 없었다면 Git을 채택하지 않았을 것이라고 확신할 수 있을 정도로 중요한 기능입니다.
UE에서 공동 개발에 꼭 필요하다고 생각한 또 다른 기능은 파일 잠금 기능입니다.
Git에는 잠금 기능이 없는데, 운 좋게도 이 기능은 UE 사용에 필수적인 Git LFS와 함께 제공되어 일석이조의 효과를 누릴 수 있었습니다.

이 플러그인이 없어도 Git으로 개발은 할 수 있긴 하지만....
비유하자면 지금 생활에서 가전제품을 빼고 살 수 있을까? 라는 느낌입니다.
이제는 공식화했으면 좋겠다는 생각이 들 정도로 중요한 플러그인입니다.
아니, 공식 Git 플러그인은 언제까지 베타 버전이냐?

 

Git 클라이언트는 회원들이 원하는 것을 사용하도록 하고 있습니다.
말하자면 개발 수단일 뿐이니 본인이 가장 효율적으로 개발할 수 있는 것을 선택하게 하는 것이 최선이라고 생각합니다.
라고 멤버들에게 설명했지만, CUI라면 Git Bash, GUI라면 Sourcetree로 양극화되었습니다.

역자 첨부
개인적으로 Git Fork 라는 소프트웨어를 주로 사용하고 있습니다. 깃크라켄 이나 소스트리, 서브라임 머지 등등 여러가지를 사용해 봤지만 스테이징 리스트 속도가 가장 빠른건 Fork 였네요. 깃크라켄은 인터페이스는 좋지만 스테이징 리스트가 많거나 변경된 파일 리스트 보여줄때 매우 자주 멤 오버플로 나고 터집니다. 개인적으로 비추 합니다.

Fork - a fast and friendly git client for Mac and Windows

저는 처음에 Sourcetree를 썼는데, CUI가 더 빠를 것 같고 & GUI라면 어떤 명령을 실행하고 있는지 의식하지 않고 & 명령어 나열? 그래야지( -´ω-`)라는 생각에 중간에 Bash로 바꿨습니다.
사내 문서도 CUI로 정비했기 때문에 Git을 전혀 접해보지 않은 분들에게는 Bash로 시작하는 것을 추천하고 있습니다.

Git - Downloading Package

개발의 흐름

저희 회사의 개발 흐름입니다.
노션의 작업은 기본적으로 제가 등록하고 있지만, 틈틈이 회원들에게도 등록을 독려하고 있습니다.
노션에 등록할 때 대략적인 사양, 개발 방침과 담당자를 결정합니다.
풀릭의 리뷰어도, 병합 승인도 그 때 그 자리에 있는 멤버라면 누구나 할 수 있는 정책으로 하고 있습니다.

1. Notion에서 태스크를 선택하여 Github에서 이슈화하기
2. develop 브랜치에서 feature 브랜치를 생성한다.
3. 개발을 진행하고 적당히 커밋한다.
4. 완료되면 푸시하고 풀릭을 생성한다.
5. 리뷰어에게 검토를 받고, 수정 사항이 있으면 해당 풀 리퀘스트 내에서 상호 작용한다.
6. 문제가 없으면 develop 브랜치에 병합한다.
7. issue를 닫고 1로 돌아간다.

UE 내 Git 작업

UE에서 Git으로 하는 작업은 거의 없습니다.
파일 잠금과 잠금 해제, 차이점 표시 정도입니다.
커밋, 풀, 푸시 등 대부분의 작업을 Git Bash나 Sourcetree로 하고 있습니다.

브랜치 운영 규칙

Git-flow를 기반으로 조금 단순화한 것을 채택하고 있습니다.
Git-flow처럼 너무 복잡하게 만들면 속도감이 떨어질 것 같아서 Git-flow를 너무 훼손하지 않고 최대한 단순하게 만들려고 노력했다.

main

릴리스 버전 관리를 위한 브랜치입니다.
이 브랜치에서는 개발을 하지 않습니다.
실제로 스토어에 릴리즈하기 위한 브랜치이며, 릴리즈 후 버전 태그를 붙인다.
브랜치 원본도 없고, 병합할 대상도 없습니다.

release

릴리스 준비용 브랜치입니다.
Shipping을 위한 설정만 하고 기본적으로 개발은 하지 않습니다.
release 준비 중에 수정하고 싶은 부분이 생기면 feature에서 수정하고, 완료 후 develop에서 병합합니다.
main에 병합한 후에는 삭제합니다.
분기 원본은 develop이고, 병합 대상은 main입니다.

develop

개발용 브랜치입니다.
이 브랜치에서는 개발을 하지 않습니다.
릴리스 전 최신 버전으로 존재하며, 가능한 한 버그가 없는 상태로 유지한다.
브랜치 원본은 없으며, 병합 대상은 release입니다.

feature

기능 개발용 브랜치입니다.
새로운 기능, 버그 수정 등 실제로 애셋을 편집할 때는 모두 이 브랜치를 생성한 후 편집합니다.
develop에 병합한 후에는 삭제합니다.
브랜치 원본은 develop이고, 병합 대상은 develop입니다.

이슈 및 풀 리퀘스트

둘 다 템플릿을 만들어서 회원들이 쉽게 내용을 공유할 수 있도록 하고 있습니다.
작성할 항목이 너무 많아도 좋지 않고, 너무 적게 쓰면 검토할 때 번거롭기 때문에 어려운 부분입니다.
지금은 검토할 때 '좀 더 세밀하게 써주세요'라고 본인의 의식을 모두에게 맞추는 방향으로 하고 있지만, 어쩌면 템플릿을 조금 더 고쳐서 구조적으로 해결해야 할 수도 있을 것 같습니다.

issueテンプレート

Pull Requestテンプレート

요약

저 개인적으로는 구체적으로 Git의 운용 사례를 썼지만, '아직은 실용적이지 않네! 내 신의 워크플로우를 알려줄게!!!!" 라며 자신의 워크플로우를 공개해 주실 유쾌한 맹자를 기다리고 있습니다.
저희처럼 소규모 팀에서 규칙을 딱딱하게 정해놓으면 속도감을 떨어뜨릴 수 있기 때문에 너무 명확하게 규칙을 정하지 않는 것이 중요하다고 생각합니다.
결국 목표는 팀의 총 생산성을 높이는 것이기 때문에 PDCA를 통해 최적화해 나가는 수밖에 없어요.
다양한 사람들의 워크플로우를 보고, 시도해보고, 도입해보고, 우리에게 가장 잘 맞는 워크플로우를 찾았으면 좋겠어요.

 

 

---

원문

Git を用いた Unreal Engine のバージョン管理の始め方を記事にまとめました！
弊社では最近、バージョン管理ツールを Perforce から Git に移行しました。
その際、かなり苦戦したので分かりやすく記事にまとめさせて頂きました。
良ければご覧下さい！#Qiitahttps://t.co/tqqhk42p37

— ModelingX | MELIFE リリース！ (@ModelingX_jp) April 24, 2024