[Git] 6. rebase & cherry-pick

🚀 rebase

---

• git rebase는 한 브랜치의 커밋들을 다른 브랜치의 최신 커밋 위에 “재배치”하여 선형적인 커밋 히스토리를 만드는 명령
• 즉, 어떤 브랜치의 변경 이력을 다른 브랜치의 변경 이력 뒤에 붙이는 것

🚀 rebase 주요 목적

---

• 히스토리 깔끔하게 유지

  복잡한 병합 커밋 없이 선형적인 커밋 히스토리를 만들어서, 프로젝트의 이력을 이해하기 쉽게 만든다.

• 작업 브랜치 최신화

  개발 중인 기능 브랜치를 main 브랜치의 최신 내용으로 업데이트하여 충돌을 미리 해결하고 깔끔하게 병합할 수 있도록 준비한다.

🚀 rebase 작동 방식

---

git rebase <대상 브랜치> 를 실행하면, 현재 브랜치에서 대상 브랜치와의 공통 조상 커밋 이후의 모든 커밋들을 임시로 분리한다. 그리고 현재 브랜치의 시작점을 대상 브랜치의 최신 커밋으로 이동시킨 후, 분리했던 커밋들을 순서대로 다시 적용한다. 이 과정에서 각 커밋의 해시(SHA-1)가 변경된다.

예시

--- A --- B --- C (main)
           \
            D --- E (feature)

feature 브랜치에서 main 브랜치로 rebase를 수행하면 (git switch feature 후 git rebase main)

1. D, E 커밋을 임시로 분리
2. feature 브랜치의 시작점을 C 커밋으로 이동
3. D와 E 커밋을 C 커밋 위에 다시 적용하여 새로운 커밋 D+, E+를 생성

결과

--- A --- B --- C --- D+ --- E+ (main, feature)

장점

• 선형적인 커밋 히스토리

• 히스토리 정리

  interactive rebase (git rebase -i)를 사용하여 여러 개의 작은 커밋을 하나로 합치거나, 커밋 메세지를 수정하거나, 커밋 순서를 변경하는 등 히스토리를 세밀하게 정리할 수 있다

단점

• 기존 커밋의 해시를 변경하기 때문에 이미 공유된(push된) 브랜치에서는 절대로 사용해서는 안된다. 다른 사람의 작업과 충돌을 일으키거나 히스토리를 혼란스럽게 만들 수 있다.

• 복잡성

  충돌 발생 시 merge 보다 해결 과정이 조금 더 복잡할 수 있다

🚀 cherry-pick

---

• git cherry-pick <커밋 해시> 를 실행하면, 지정된 커밋의 변경 사항을 현재 브랜치에 새로운 커밋으로 생성하여 적용한다.
• 원본 커밋의 해시는 유지되지 않고 새로운 커밋이 생성된다.

예시

--- A --- B --- C (main)
           \
            D --- E --- F (feature)

main 브랜치에서 feature 브랜치의 E 커밋만 cherry-pick 하려면 (git switch main 후 git cherry-pick E_COMMIT_HASH)

결과

--- A --- B --- C --- E+ (main)
           \
            D --- E --- F (feature)

• 여기서 E_COMMIT_HASH는 E 커밋의 실제 해시 값이다.
• E+ 는 E 커밋의 변경 사항을 담고 있는 main 브랜치에 새로 생성된 커밋

장점

• 선택적 적용

  필요한 커밋만 정확히 선택하여 가져올 수 있다.

• 안정성

  기존 히스토리를 변경하지 않고, 새로운 커밋을 생성하여 적용하므로 이미 공유된 브랜치에서도 상대적으로 안전하게 사용할 수 있다.

단점

• 히스토리 중복

  같은 변경 사항이 여러 브랜치에 서로 다른 커밋으로 존재할 수 있어 히스토리가 다소 지저분해질 수 있다.

• 오용 시 복잡성

  너무 자주 사용하면 히스토리가 복잡해지고, 나중에 병합 시 충돌 해결이 어려워질 수 있다.