원격 브랜치가 rebase된 뒤 push가 거부될 때

배경

Unity 프리팹 같은 디자인 리소스 파일은 git merge 시 diff만으로 conflict를 해결하기 어렵다.

슬롯 콘텐츠는 운영 툴에서 노출 여부를 제어할 수 있어, master가 배포되어도 문제가 없으므로 평소에는 master에서 작업했다. 디자인 작업자들은 conflict를 예방하려고 파일 작업의 시작과 끝을 서로 공유했다.

문제

master에서 분기한 feature 브랜치에서 작업하면 작업자의 로컬 커밋 트리와 원격 커밋 트리가 달라질 수 있다. 작업을 마치고 push하려는데 pull 받을 커밋 58개, push할 커밋 370개가 표시되는 식이다.

원인

원격의 feature 브랜치(feature/collection)가 rebase되어, rebase 이전 상태를 가진 작업자의 로컬 커밋 트리와 달라졌기 때문이다.

이 상태에서 push하면 merge conflict가 날 수 있고, 나지 않더라도 트리가 달라 push가 거부된다.

해결

push 전에 로컬에서도 원격 브랜치를 기준으로 rebase한 뒤 push한다. 소스트리 기준 절차는 다음과 같다.

1. 작업 내용을 평소처럼 커밋한다.
2. push 전에 fetch를 누른다.
3. push한다. 성공하면 이후 과정은 생략한다. 트리가 다르면 rejected non-fast-forward 에러 팝업이 뜬다.
4. 이때 pull을 누르지 않는다(conflict가 날 수 있다). 원격 브랜치(origin/feature/브랜치이름)를 오른쪽 클릭해 [재배치] 또는 [rebase current changes onto …]를 실행한다. 에러가 없으면 6으로 간다.
5. 예상되는 에러는 두 가지다.
   • 로컬에 커밋되지 않은 변경점이 있는 경우: unstaged 작업 영역을 커밋하거나 stash해서 비운다.
   • rebase 과정에서 특정 파일에 conflict가 나는 경우
     • .meta 파일은 최초로 push한 작업자의 파일을 쓰는 것이 맞으므로 내 로컬의 충돌 파일을 revert한다.
     • .prefab처럼 여럿이 함께 작업하는 파일은 커밋 로그를 보고 작업자끼리 확인해야 한다. 작업 시작과 끝을 공유하고 있다면 생길 일이 없다.
6. pull 받을 커밋 수가 0인 상태에서 push한다. rebase가 정상적으로 되었다면 conflict가 날 수 없다. 그래도 rejected non-fast-forward가 나거나 pull/push 개수가 비정상적이면 상태를 다시 확인해야 한다.