Git 커밋 히스토리를 깔끔하게 유지하는 비결: git pull --rebase 활용법

핵심 기술: 이 콘텐츠는 Git에서 git pull 명령의 기본 동작인 병합(merge) 방식 대신 git pull --rebase를 사용하여 커밋 히스토리를 선형적으로 유지하는 방법을 설명합니다. 이를 통해 협업을 용이하게 하고 히스토리 추적성을 높입니다.

기술적 세부사항:
* git pull vs git pull --rebase:
* git pull: 원격 변경 사항을 가져온 후(git fetch) 현재 브랜치에 병합(git merge)하여 병합 커밋을 생성합니다.
* git pull --rebase: 원격 변경 사항을 가져온 후(git fetch), 로컬 커밋을 잠시 제거하고 원격 변경 사항을 적용한 뒤, 로컬 커밋을 다시 최신 상태 위에 순차적으로 적용하여 선형적인 히스토리를 만듭니다.
* 히스토리 관리: 병합 커밋 없이 깔끔한 선형 히스토리를 유지할 수 있어 git log --graph 등으로 히스토리를 파악하기 용이합니다.
* 활용 시나리오:
* main 브랜치에 병합 커밋 없이 깨끗한 히스토리 유지 (CI/CD 연동 시 유용)
* 의존성이 있는 피처 브랜치 간 동기화
* 푸시 전 커밋 메시지 수정, 병합 등 히스토리 정리 (git rebase -i와 함께 사용)
* 장기간 작업 브랜치에서 최신 원격 변경 사항을 자주 동기화할 때
* Force Push된 main 브랜치와 동기화
* 고급 옵션:
* --autostash: rebase 과정 중 로컬 변경 사항 자동 임시 저장 및 복구
* --fork-point: 브랜치가 분기된 지점을 지능적으로 찾아 rebase
* 주의사항:
* 이미 푸시된 커밋 히스토리를 변경하는 것은 다른 협업자에게 문제를 일으킬 수 있습니다.
* 태그가 지정된 릴리스 커밋을 rebase하면 태그가 깨질 수 있습니다.
* 명시적으로 병합 커밋이 필요한 경우(예: 큰 기능 통합 추적)에는 병합 방식을 사용해야 합니다.

개발 임팩트: 협업 시 발생할 수 있는 복잡한 히스토리 문제를 줄여주고, 코드 변경 사항의 흐름을 쉽게 파악할 수 있도록 돕습니다. 또한, 코드 리뷰 준비 및 원활한 CI/CD 파이프라인 구축에 기여하여 개발 생산성과 코드 품질을 향상시킬 수 있습니다.