Git Cherry-pick, Rebase

Cherry Pick과 Rebase는 두 가지 다른 Git 작업으로, 둘 다 브랜치 간의 커밋을 다루는 데 사용됩니다. 이 두 명령어는 개별 커밋의 재배치나 선택적 병합을 가능하게 하여 코드베이스의 유지 관리를 더 유연하게 합니다.

Cherry Pick

Cherry Pick은 다른 브랜치에서 특정 커밋 하나 또는 여러 개를 선택해서 현재 브랜치에 적용할 때 사용합니다. 이 방법은 특정 변경사항만을 현재 작업중인 브랜치로 가져오고 싶을 때 유용합니다.

주요 사용 사례

• 특정 기능이나 버그 수정이 포함된 커밋을 하나의 브랜치에서 다른 브랜치로 이전하고 싶을 때 사용합니다.
• 대규모 병합이 필요 없는 작은 변경사항을 관리할 때 유용합니다.

작업 과정

1. 원하는 커밋의 해시 ID를 찾습니다.
2. git cherry-pick [커밋 ID] 명령어를 사용하여 해당 커밋을 현재 브랜치에 적용합니다.

예시 

1. master에서 feature/test-1 브랜치를 생성하고 해당 브랜치에서 Commit A , B , C 를 생성 (각각 내용을 A,B,C로 바꾸는 커밋)

 

 

2. 다시 master 브랜치로 Check Out후에 Commit B의 작업 (내용을 B로 변경) 을 가져오고 싶을때 Cherry pick을 선택

 

 

3. 현재 master에서는 내용이 '1' 이고 cherry pick으로 가져오는 Commit B의 값은 'B' 이므로 Conflict가 발생

 

4. Conflict를 처리하게 되면 자동으로 Commit이 실행되고 아래와 같이 Master에서 새로운 Commit이 생성됨

 

Rebase

 

Rebase는 하나의 브랜치가 시작된 지점을 다른 지점으로 이동하거나, 다른 브랜치의 최신 상태로 업데이트하기 위해 사용됩니다. 이 작업은 커밋 히스토리를 깔끔하게 유지하는 데 도움이 됩니다.

Before Rebase

 

After Rebase

 

주요 사용 사례

• 브랜치의 기반을 최신 상태로 업데이트하여, 마치 해당 브랜치가 최근에 분기된 것처럼 보이게 합니다.
• 커밋 히스토리를 선형으로 정리하여 복잡성을 줄이고, 이해하기 쉽게 만듭니다.

작업 과정

1. git rebase [기반 브랜치] 명령어를 사용합니다.
2. 현재 브랜치의 모든 변경사항을 임시로 저장하고, 기반 브랜치를 최신 상태로 업데이트합니다.
3. 임시로 저장된 변경사항을 하나씩 새로운 기반 위에 재적용합니다.

예시 

1. Mater 브랜치에서 test-1 브랜치가 생성되고 test-1 에서는 commit A,B,C(각각 값을 A,B,C로 변경)  생성 (각각 값을 A2,B2,C2로 변경) 에서는 Mater에서는 Commit 2, Commit 3가 (각각 값을 1 ,2로 변경) 생성됨

 

2. Master 브랜치로 Check Out후에 test-1를 Rebase함

 

 

3. Test-1의 Commit들에 대해서 Master에서 순차적으로 병합을 하게됨( Conflict 발생할 수 있음)

conflict 발생

 

 

3-1 . Accept Yours 선택시에 Master의 최신 브랜치(Commit 3) 가 유지되고 Test-1의 commit들이 현재 브랜치의 commit에 포함됨

Rebase Commit 추가됨

test-1의 A,B,C가 포함됨

 

3-2. Accept Theirs 선택시에는 Rebase 후에 Mater 브랜치의 최신 상태는 test-1의 Commit C의 상태가 되었고 Master에서 생성되었던 commit은 모두 삭제됨 

Accept Theirs

 

Master에서 해당 브랜치를 Rebase하는것이므로 Accept Theirs를 선택하는것이 일반적 , 즉 해당 브랜치로 Base를 변경하는것을 Rebase라고 정의할수 있습니다.

 

 

Merge와 차이점

 

merge의 결과

 

 

Rebase대신 Merge를 한 결과 (Accept Theirs)

• Rebase는 현재 브랜치의 커밋을 모두 임시로 저장하고, 이를 대상 브랜치의 최신 커밋 끝에 하나씩 다시 적용하는 과정입니다. 이로써 마치 현재 브랜치가 대상 브랜치의 최신 상태에서 새로 시작된 것처럼 커밋 히스토리를 재구성합니다.
• 이미 공개된 브랜치에 rebase를 수행하면 커밋 히스토리가 변경되어, 팀원들이 같은 브랜치의 이전 상태를 기준으로 작업하고 있을 경우 혼란이 발생할 수 있습니다.
• Merge는 두 브랜치의 최신 커밋을 통합하여 새로운 '병합 커밋'을 생성합니다. 이 병합 커밋은 두 브랜치의 변경사항을 모두 포함하며, 각 브랜치의 커밋 히스토리를 유지합니다.
• Merge는 커밋 히스토리가 비선형적이 되어 복잡해질 수 있습니다. 이는 히스토리를 추적하고 이해하는 데 어려움을 줄 수 있습니다.

선택 기준

• 개인 개발 또는 소규모 팀에서는 Rebase를 사용하여 깔끔한 커밋 히스토리를 유지하는 것이 좋을 수 있습니다.
• 큰 팀 또는 여러 기여자가 있는 프로젝트에서는 Merge를 사용하여 각 기여자의 작업을 명확하게 보존하는 것이 협업에 더욱 적합할 수 있습니다.