git cherry-pick으로 rebase 완성하기

문제의 시작은 Merge가 되기도 전에 다른 branch에서 작업을 하다가 Merge가 된 후에 기본 branch의 작업을 가져와야 했었다. 이것을 rebase로 해결한 사례이다.

우선 Merge와 Rebase의 차이는 아래와 같다.

Rebase와 Merge의 차이점

이 두 브랜치를 합치는 가장 쉬운 방법은 merge 명령을 이용해 3-way Merge로 새로운 커밋을 만들어내는 것이다.
이 때 내부적으로 공통조상인 C2를 이용하게 된다.

두 브랜치가 나뉘어 있는 아까와 같은 상황에서 시작한다.

대강 여기서 rebase를 이용할 예정이다. 왜냐하면 커밋이 깔끔하기 때문에.

전체 흐름을 파악했다면 문제인 요소에 대해 디테일하게 접근해보자.

문제는 다음과 같다.

next-step::racing_car 라고 하는 레포지토리를 나의 브랜치로 fork 해왔다.

그리고 step1의 작업을 완료하고 Merge 하였다. 이때, Merge가 승인되지 않은 상태에서 나는 새로운 브랜치를 따서 작업을 수행하고 커밋을 쌓았다.

Merge가 승인 되었다. 근데 이게 왠걸? 충돌..?

문제점의 포인트는 새로운 브랜치에 작업을 수행할 때 기존에 Merge된것을 기반으로 한것이 아니여서 문제가 되었다.

그래서 나는 step1에서 pr날려서 Merge가 된것을 나의 repo로 돌아와서

로컬에 수행 시 git repository의 upstream의 로컬로 땡겨와 내 repository로 add remote를 수행하면 Merge된것을 가져올 수 있다.

여기서 Step2의 변경사항을 cherry-pick하면 된다

그럼 cherry-pick은 왜 발생할까? 이미 커밋 이력이 존재하는곳에 내가 다른 분기를 생성해 같은 부분을 수정하는 커밋이력 부분을 작성했기 때문이다.

예를들면, Car 클래스를 수정하다가 커밋을 쌓고 있는데 기존에 Merge되지 않는 것이 이미 Commit으로 존재한다고 가정하자.

이럴때, 커밋에 변경사항에 대한 정보가 충돌나게 된다.

핵심은 분기가 생길 때 조심해야 한다는것

cherry-pick 관련된 명령어는 하기와 같다.

git cheery-pick 841cb87

!Tip

git cherry-pick --abort 중단을 물어볼 수 있다. (정확히 왜 물어보는지는 모르겠음 이럴 경우)

해당 브랜치에 대해서 init을 선행한다. or reset --hard 나?