Git-Flow 협업 방식 (With. Unreal Engine)

회사에서 사용하는 깃 협업 방식을 정리해보았습니다.

 

팀 포트폴리오 제작 시에 활용하시면, 서류 제출시에 꽤나 좋게 봐주실듯 합니다.

---

 

 

0. 프로젝트 clone

  - git clone 후에 바로 feature 브랜치 생성

    feature 브랜치 생성 후 체크 아웃하고 빌드해야 함. 

    내 로컬의 빌드 파일들이 원격에 올라가지 않아야 하기 때문.

    원격의 빌드 파일들이 바뀌면 아트팀 분들이 pull 할 경우 다시 빌드해야 함.

    근데 아트팀 분들은 IDE가 없기 때문에 빌드할 수 없음.

 

1. 코드 작업 후 feature 브랜치 commit

  - Content 폴더 우클릭 > Fix Up Redirectors 해주기.

    클래스 이름 변경이나 에셋 경로 정보 변경시에 언리얼 자체적으로 문제가 안생기게끔 도와주는 기능.

  - 안쓰는 코드 정리. (Rider에서는 회색으로 안쓰는 코드들이 표시됨)

  - 마지막 확인으로 빌드 및 플레이 확인.

  - 라이브코딩 혹은 핫리로드로 인한 .dll 파일 제거.

  - commit 하기 전 add에서 .dll 파일들은 unstaging

    plugin 폴더 속의 .dll 파일들도 unstaging [중요]

  - 사내 커밋 컨벤션 확인 후 해당 컨벤션에 맞춰서 commit message 작성 후 commit

 

2. 백업용 branch 생성

  - 앞으로의 단계에서 충돌을 해결하지 못하거나, 작업물이 날아갈 수도 있음.

    반드시 앞서 생성한 feature 브랜치를 백업해둬야함.

 

3. main 브랜치로 checkout 후 pull로 최신화

  - 다음 단계에서 main 브랜치로 feature 브랜치를 rebase 할 예정이기 때문임.

 

4. feature 브랜치로 checkout 후 main 브랜치로의 rebase

  - rebase를 진행하면 충돌이 발생할 수도 있음.

    -- rebase 도중에 충돌이 발생하면 HEAD 브랜치로 체크아웃 됨.

      이는 신경쓰지 않아도됨. 뒤에 rebase 계속 진행을 수행하면 자연스럽게 사라짐.

      만약 HEAD 브랜치가 rebase 계속 진행 후에도 사라지지 않는다면 그냥 삭제.

    -- .ini 파일에서 다른 팀원의 내용과 충돌할 경우에는 대부분 둘 다 포함되어야 함.

      해당 .ini 파일을 열어서 git 관련 내용(3줄정도됨)을 지우고 저장. 해당 변경사항을 mark resolved 처리.
      또는 SourceTree에서 충돌난 파일을 우클릭 > resolve conflict > 'Mine'(이상하게도 Mine으로 해야 내 작업물이 사라짐)
      내 작업물을 일단 날리고 동료의 내용으로 적용되게끔 한 다음 다시 작성 하는 방식.

    -- 충돌 해결 후에는 git rebase --continue 명령을 수행.

  - rebase 후에 내 작업 내용이 반영 되었는지 빌드 후 플레이

    rebase가 성공하면 원격의 .dll 파일이 들어옴. 따라서 다시 빌드해서 내 작업과 합쳐야함.

    빌드 후 플레이하는데 문제가 생긴다면, 블루프린트 관련 설정이 초기화 된 경우일 수 있음.

    다시 설정 후에 빌드 & 플레이. (이 때문에라도 C++ 위주 작성이 중요하긴 함)

  

5. rebase 후에 빌드 commit

  - 내 작업이 반영된 .dll 파일을 commit

    이때는 1번에서 작성한 commit message 뒤에 "빌드"라고 작성함.(이건 우리 회사의 규칙)

    commit message 내의 상세 내용은 생략. 1번에서 작성했을 것이기 때문.

    

6. main 브랜치로의 merge

  - main 브랜치로 checkout 

  - feature 브랜치를 main 브랜치로 merge

    이때도 충돌 발생 할 수 있음. 앞선 단계에서 dll 파일 관리를 제대로 하지 않은 경우.

    이경우엔 백업용 branch로 돌아가서 다시 진행하도록 하자. (확실치않음...)

 

7. main 브랜치의 push

  - push 후에는 feature 브랜치와 백업용 feature 브랜치는 일단 살려둠.

    추후에 또 문제 발생할 수 있음..

  - 새롭게 feature 브랜치 생성 후 다시 작업. 1번부터 반복.

 

8. 테스트 방법

  master 브랜치는 위에서 보았듯 개발용 브랜치임.

  개발용 브랜치의 검증이 끝났다면 release 브랜치로 내용을 옮겨야함.

  1. Local Master 브랜치에서 Remote Release 브랜치로 Push.

    단, 이경우에는 Master 브랜치의 빌드에 문제가 없는지 테스트 하고 Push 해야함.

  2. 1번 방법에서 문제가 있을 경우

    Local Release 브랜치에서 Fetch / Pull로 최신화.

    원하는 Commit 우클릭 > Reset to hard

    Local Release 브랜치에서 Remote Release 브랜치로 Push.