본문 바로가기

Git

[Git] Merge 할 때, Fast-forward 방식은 무엇인가?

반응형

이번 포스팅에서는 git 에서 하나의 브랜치에서 다른 브랜치의 파일을 Merge 하거나 또는 원격 저장소에서 Pull을 하거나 할 때 메세지로 Fast-forward 방식이라는 메세지가 등장한다. 이에 대해서 잘 설명해주시는 이고잉님의 강의도 있고 git 공식 문서에도 친절하게 소개되어 있다. 강의를 바탕으로 배운 내용을 기록해보려 한다.

 

Github


우선, 아래와 같이 현재 master 브랜치에서 3개의 커밋 C0, C1, C2가 완료된 상태라고 가정해보자. 아래의 그림을 보면 화살표는 과거를 가리키는데, 이는 '부모' 커밋을 의미한다. 어쨌거나 시간 순서대로 하면 C0이 가장 오래 전에 한 커밋, C2가 가장 최근에 한 커밋이다.

 

 

이제 여기서 우리는 하나의 기능을 추가하기 위해서 master 브랜치와 버전이 동일한 iss53 이라는 새로운 브랜치를 다음과 같이 만들었다.

 

 

그리고 iss53 브랜치에서 기능 하나를 추가해서 커밋을 새로 하나 수행했다. 그렇게 한 후 워크 트리의 구조가 다음과 같이 변했다.

 

 

그런데, 갑자기 문제가 생겼다. 기존의 master 브랜치의 파일에서 에러가 발생해 수정할 사항이 생겨서 또 하나의 브랜치 hotfix 를 만들고 새로운 커밋 C4를 새롭게 커밋했다. 그렇게 하니 워크 트리의 구조가 다음과 같이 변했다.

 

 

이제 에러도 수정했고 에러를 수정한 파일의 버전으로 master를 이동시켜야 한다. master 브랜치로 checkout 해서 hotfix 브랜치를 merge 한다. 그렇게 되면 워크 트리가 다음과 같이 변한다.

 

Fast-forward merge 결과

 

바로 이 merge 즉, master 브랜치로 checkout 해서 hotfix를 merge 했을 때가 바로 Fast-forward 방식의 merge 이다. 즉, A 브랜치에서 다른 B 브랜치를 merge 할 때 B 브랜치가 A 브랜치 이후의 커밋을 가리키고 있으면 그저 A 브랜치가 B 브랜치와 동일한 커밋을 가리키도록 이동시킬 뿐이다. 이 방식은 별도의 merge 커밋을 생성하지 않고 바로 merge 시킨다.

 

그렇다면 Fast-forward 방식이 아닌 merge는 무엇일까? 이제 master 브랜치와 hotfix 브랜치가 동일한 곳을 가리키니까 hotifx는 거추장스러우니 hotfix 브랜치를 삭제시키자. 그리고 iss53 브랜치에서 새로운 커밋 C5를 만들어 커밋했다고 해보자. 그러면 워크 트리의 구조가 다음과 같이 변한다.

 

 

이제 나누어진 브랜치를 하나의 버전으로 통합시키기 위해 iss53 브랜치와 master 브랜치를 병합시키기로 한다. 또 master 브랜치로 checkout 해서 iss53 브랜치를 merge 한다. 이렇게 merge 하는 방식을 'recursive' 방식이라고 한다. 그러면 Fast-forward 와 recursive의 차이점은 무엇일까?

 

 

위 그림은 recursive merge을 수행할 때의 그림이다. 즉, 현재 가리키는 master 브랜치가 병합할 iss53 브랜치의 조상이 아니다. 따라서 이 때는 master 브랜치가 가리키는 커밋 1개, iss53이 가리키는 커밋 1개, 그리고 master, iss53의 공통 조상인 C2를 사용하여 3-way merge를 하게 된다. 따라서 3-way merge를 수행한 결과, 워크 트리 구조는 다음과 같아진다. 참고로 3-way merge인 recursive merge 방식은 Fast-forward 방식과는 달리 별도의 merge 커밋을 생성한다.

 

3-way merge 결과

 

반응형