Cherry-pick과 Rebase, Fast-forward - 병합커밋 없이 git history 깔끔하게 하는 방법

Cherry-pick과 Rebase의 공통점

 

cherry-pick과 rebase는 목적은 다르지만 동작하는 방법이 거의 비슷하다.  두 작업 모두 병렬적으로 작업된 목록을 하나로 합친다는 공통점이 있다. cherr-pick, rebase를 이해하기 위해서는 우선 git이 소스를 합치는 방식인 3 way merge에 대한 이해가 필요하다.

 

 

Cherry Pick 이란?

cherry-pick은, 병렬적으로 작업된 내용에서 특정 commit을 선택하여 새로운 버전을 만들어 내는 방법이다.  이때 새로운 버전을 만들기 위해 3 way merge를 수행한다.

 

Rebase 란?

rebase라는 단어 뜻 그대로, base(각 브랜치들의 공통 조상 commit)를 옮긴다는 뜻이다. 

 

다음 예제를 보자.

git checkout branchA;

git rebase branchB;

 

다음 명령어를 수행하면, branchA의 base commit은 branchB의 마지막 commit으로 대체 된다.  이렇게 하면 Merge시 발생하는 병합 커밋이 생성되지 않으므로 git history를 깔끔하게 관리할 수 있다.

 

병렬적으로 구현된 소스 코드들을 어떻게 합칠것이냐의 방식 차이일 뿐이기 때문에, merge와 rebase 모두 결과 파일은 동일하다.

 

rebase를 쓸 때 특히 주의해야할 점은,  remote에 push 하기 전, local에서만 수행해야하는 것이다. 이미 올라간 remote에 대해서 rebase 하는 것은 rebase가 commit hash값을 변경시키기 때문에 협업 시 큰 문제를 일으킬 수 있다.  다른 개발자들은 특정 시점의 remote commit을 기반으로 local에서 작업을 수행할 텐데,  기준이된 remote commit의 hash 값이 변경되면 히스토리 충돌이 발생하게 된다.

 

remote 소스를 Pull 받아올 때  Merge remote-tracking branch 'origin/master'와 같은 default merge 메시지를 생략하기 위해 git pull --rebase를 사용할 수 있다.  옵션을 추가하지 않으면 pull 명령어는 기본적으로 merge를 통해 소스 병합을 수행하기 때문에,  병합 커밋이 생성된다.

 

물론 소스 파일에서 충돌 내용이 없다면, 간단하게 fast-forward를 사용해서 병합커밋을 생략하는 방법도 있다.

 

git merge --ff-only

 

 

• fast-forward란?

현재 브랜치를 단순히 병합 대상 브랜치의 최신 커밋으로 "앞으로 전진"시키기는 것을 의미한다.  예를들어 A branch에 대해 remote 서버, 즉 origin/A 에서 최신 커밋을 Pull 받아 왔다고 가정해 보자. 그러면 이때 Local의 Head는 origin/A가 아니라 local에 있는 A의 마지막 커밋을 가리키고 있을 것이다. 이때 이 Head를 단순히 remote에서 받아온 마지막 commit으로 옮김으로써, 별도의 병합 커밋을 생략하게 되는 것을 의미한다.