Git rerere 사용법

본문 중간의 쿠팡 추천 상품 구매시 쿠팡 파트너스에서 일정액의 수수료를 제공받습니다.

Git rerere 사용법

git rerere는 같은 충돌을 다시 만났을 때 이전에 해결한 결과를 재사용하도록 돕는 기능이다. 2026년 6월 10일 기준 Git 공식 문서를 보면 이 기능은 반복되는 merge conflict를 줄이는 데 초점이 있고, 사용 전에는 rerere.enabled 설정 여부를 먼저 확인해야 한다.

실무에서 핵심은 세 가지다. 충돌이 자주 반복되는 브랜치 구조인지, 자동으로 index까지 갱신할지, 그리고 자동 적용 후 사람이 다시 검토할지다. 이 글은 Git 공식 문서 기준으로 rerere의 동작 방식과 안전한 사용 기준만 정리한다.

git rerere는 무엇을 기록할까?

공식 문서의 설명대로 rerere는 처음 충돌이 났을 때 충돌 마커가 들어 있는 자동 병합 결과와, 이후 사용자가 직접 고친 최종 해결 결과를 함께 기록한다. 나중에 같은 충돌 hunk를 다시 만나면 이 기록을 바탕으로 해결 결과를 재적용한다.

즉 단순히 "파일 이름이 같으면 재사용"하는 기능이 아니라, 이전 충돌 패턴과 해결 결과를 연결해 두었다가 비슷한 충돌이 다시 발생했을 때 재사용하는 구조다. 장기간 유지되는 topic branch에서 같은 충돌을 여러 번 푸는 상황에 특히 유용하다.

먼저 어떤 설정을 켜야 할까?

git-rerere 문서는 이 기능을 쓰려면 rerere.enabled를 설정해야 한다고 설명한다. 다만 git-config 문서 기준으로는 저장소의 $GIT_DIR 아래에 rr-cache 디렉터리가 이미 있으면 기본적으로 활성화될 수 있다.

처음부터 명시적으로 쓰려면 다음처럼 설정하는 편이 가장 분명하다.

git config --global rerere.enabled true
git config --global rerere.autoUpdate false

rerere.autoUpdate 기본값은 false다. 공식 문서 기준 이 값을 true로 두면 이전 해결 결과를 깨끗하게 재사용했을 때 working tree뿐 아니라 index까지 함께 갱신한다.

rerere.autoUpdate는 언제 켜는 편이 맞을까?

자동으로 git add 된 상태까지 만들고 싶다면 rerere.autoUpdate=true를 검토할 수 있다. 반대로 자동 적용 결과를 먼저 눈으로 점검하고 싶다면 기본값인 false를 유지하는 편이 안전하다.

Git 공식 문서는 git merge --no-rerere-autoupdate 옵션을 사용하면 자동 해결 후에도 index 갱신을 막고 결과를 다시 검토할 수 있다고 설명한다. 반복 충돌이 많아도 코드 영향 범위가 넓다면 이 쪽이 더 보수적인 선택이다.

상황	권장 선택	이유
같은 충돌을 자주 반복하고 해결 패턴이 안정적임	rerere.autoUpdate=true	반복 입력과 git add 단계를 줄일 수 있다
자동 적용 결과를 반드시 diff로 확인해야 함	rerere.autoUpdate=false	index 자동 갱신을 막고 수동 검토 흐름을 유지할 수 있다
이번 merge에서만 보수적으로 확인하고 싶음	git merge --no-rerere-autoupdate	전역 설정을 바꾸지 않고 현재 merge에만 적용 가능하다

실제로 어떤 흐름에서 도움이 될까?

공식 예시는 장기간 유지되는 topic branch를 최신 기본 브랜치와 자주 맞춰 보는 경우를 보여 준다. 테스트용 merge를 한 번 수행하면서 수동 충돌 해결을 기록해 두면, 이후 비슷한 충돌이 다시 발생했을 때 같은 해결을 재사용할 수 있다.

Git 문서는 git merge가 자동 병합 실패 후 git rerere를 자동 호출하고, merge 결과를 커밋할 때도 관련 기록을 반영한다고 설명한다. 그래서 기능을 켠 뒤에는 대부분 별도 명령을 자주 직접 입력하지 않아도 된다.

 

 

그래도 직접 확인할 수 있는 명령은 무엇일까?

git rerere에는 현재 상태를 점검하는 하위 명령이 있다. 공식 문서 기준으로 자주 보는 항목은 다음과 같다.

• git rerere status: 현재 충돌 중이며 기록 대상이 되는 경로를 본다.
• git rerere diff: 해결 과정에서 무엇이 바뀌었는지 diff로 확인한다.
• git rerere remaining: 자동 해결되지 않았거나 추적할 수 없는 충돌 경로를 본다.
• git rerere gc: 오래된 기록을 정리한다. 공식 기본값은 미해결 15일, 해결됨 60일이다.
• git rerere forget <path>: 현재 충돌 경로에 대해 저장된 해결을 다시 잊게 한다.

특히 remaining은 rerere가 처리하지 못한 경로를 빠르게 분리하는 데 유용하다. 공식 문서에는 conflicting submodule처럼 추적 대상이 아닌 경우도 포함될 수 있다고 적혀 있다.

자동 적용 뒤에도 왜 검토가 필요할까?

Git 공식 문서는 rerere가 working tree 파일을 갱신해도 index는 그대로 둘 수 있으며, 최종적으로는 git diff로 내용을 확인하고 git add해야 한다고 설명한다. 자동 재사용은 반복 작업을 줄여 주지만 의미상 올바른 병합인지까지 대신 판단해 주는 기능은 아니다.

따라서 같은 코드 조각이 보여도 주변 문맥이 달라졌을 수 있는 리팩터링 구간이나 설정 파일에서는 자동 적용 후 review를 생략하지 않는 편이 안전하다.

자주 헷갈리는 질문

Q. git rerere는 merge에서만 동작할까?

공식 문서는 merge 중심으로 설명하지만, 충돌 해결 중 git rebase --abort나 git am --abort에서도 관련 정리 동작이 자동 호출된다고 명시한다. 즉 merge 외의 충돌 흐름에서도 rerere 기록이 연결될 수 있다.

Q. 기능을 켜면 충돌을 항상 완전히 자동 해결할까?

아니다. 공식 문서도 "이전에 기록한 해결이 현재 충돌에 clean하게 적용될 때" 재사용한다고 설명한다. 패턴이 충분히 다르거나 추적 불가능한 충돌이면 사람이 다시 개입해야 한다.

Q. 기록을 잘못 학습했다면 어떻게 할까?

현재 충돌 경로에 대해 잘못된 해결을 버리려면 git rerere forget <pathspec>를 사용할 수 있다. 전체 메타데이터를 초기화해야 하는 경우에는 git rerere clear도 공식 하위 명령으로 제공된다.

선택 기준을 한 번에 정리하면?

같은 충돌을 여러 번 푸는 브랜치 운영이라면 rerere.enabled=true는 검토 가치가 높다. 다만 자동으로 index까지 바꾸는 rerere.autoUpdate는 팀의 검토 습관에 맞춰 켜고, 확신이 없으면 false 또는 --no-rerere-autoupdate 쪽이 더 안전하다.

2026년 6월 10일 기준 Git 공식 문서 기준으로 보면 rerere의 장점은 "반복 충돌의 재입력 감소"이지 "검토 생략"이 아니다. 자동 적용 뒤에도 diff 확인을 포함한 마지막 점검은 유지하는 편이 무난하다.

참고 자료

• Git 공식 문서: git-rerere
• Git 공식 문서: git-config
• Git 공식 문서: git-merge