💿 이 글의 목적
rebase에 대한 기본적인 개념도 모른 채 급해서 무지성 rebase를 해버렸다. 결과는...
짜잔! 나중에 push 하려니까 이런 에러가!
rebase에 대한 공식 문서를 찾아보니 우선 merge에 대한 이해를 기본으로 설명하고 있다. 일단 merge부터 확실히 잡고 가자.
저번엔 급했지만 모처럼 이렇게 여유있는 날에 확실히 알아놓고 넘어가야 똑같은 잘못을 반복하지 않는다.
💿 git merge
merge는 경영 용어인 인수합병을 뜻하는 M&A에서 M을 담당하고 있는 친구다. 말 그대로 두 branch를 병합을 시키는 커맨드고 실제로 프로젝트 중에 기능 브랜치가 완성이 돼서 pr을 올리면, 리뷰 후에 원격 마스터로 머지가 되고, 다시 로컬 마스터로 풀 받는 식으로 잘 써먹었다. 근데 문서를 보니 내가 제대로 알지도 못하고 쓰고 있었다.
💾 merge case : fast-forward
위 그래프와 같이 iss53 브랜치가 master 브랜치의 파생 브랜치이고, 파생된 이후 master 브랜치에 추가 커밋이 없었다면 iss53의 커밋 로그는 master 브랜치 커밋 로그에서 +@ 됐을 뿐이다. 이 경우 master 브랜치에서 iss53 브랜치를 merge시키면 별도의 커밋 없이 master 브랜치가 C3으로 이동하면서 iss53의 커밋 로그를 그대로 가져온다.
💾 merge case : 3-way
하지만 위와 같은 상황이 생긴다면 fast-forward 방식으로 merge가 불가능하다. iss53이 merge 되기 전 이미 master에서 커밋이 추가로 발생했기 때문이다. 즉, iss53의 커밋 로그는 fast-forward처럼 master의 커밋 로그 +@ 의 상태가 아니다.
그래서 위와 같이 마스터 브랜치의 기존 커밋 로그 + 마스터 브랜치의 새로 추가된 커밋 로그 + iss53 브랜치의 커밋 로그 셋을 합친다.
결과적으로 이렇게 merge를 위해서 새로운 커밋을 하게 된다.
기존 커밋 로그 + 새로 추가된 커밋 로그 + 다른 브랜치의 커밋 로그 = 총 3개의 커밋 로그가 필요하기 때문에 3-way라고 부르는 것 같다.
💿 conflict
그런데 3-way 방식의 merge를 진행하게 될 경우 conflict, 즉 충돌이 발생할 수 있다. 3-way를 설명한 그림의 경우를 예로 들면, C4의 작업 공간과 C5의 작업 공간이 같은 상황에서는 git 입장에서는 둘 중에 어떤 내용을 커밋해야할지 모르기 때문에 충돌이 나버리는 것이다.
💿 뱀발
rebase도 같이 포스트하려고 했지만 생각보다 merge에 대한 이해도도 굉장히 낮은 상태였고 rebase 과정도 생각보다 복잡했다. rebase는 화요일까지 꼭 정리할 것!
Reference
