Git rebase 충돌 자동해결 - rerere 실전 설정

서로 다른 브랜치에서 같은 파일을 자주 만지는 팀이라면 git rebase는 생산성을 올려주지만, 반복 충돌이 누적되면 금방 피로해집니다. 특히 장수 브랜치(오래 살아남는 기능 브랜치)나 체리픽/리베이스를 자주 하는 레포에서는 같은 충돌을 “매번” 똑같이 푸는 일이 흔합니다.

이때 가장 강력한 숨은 기능이 rerere입니다. 한 번 해결한 충돌의 “해결 결과”를 Git이 기록해두고, 다음에 동일/유사 충돌이 다시 발생하면 자동으로 그 해결을 재적용합니다. 즉, 사람의 손으로 해결한 충돌을 Git이 학습하는 셈입니다.

이 글에서는 rerere의 동작 원리, 켜는 방법, 기록을 안전하게 관리하는 팁, 그리고 rebase 실전 흐름에서 어떻게 체감 효율을 극대화하는지까지 다룹니다.

rerere란 무엇이고 왜 rebase에 특히 유용한가

rerere는 “reuse recorded resolution”의 약자입니다.

충돌이 발생하면 Git은 충돌 난 파일의 상태(충돌 베이스/양쪽 버전)와 사용자가 최종적으로 만든 해결 결과를 기록합니다.
이후 같은 형태의 충돌이 다시 발생하면, Git이 과거 기록을 찾아 3-way 머지 과정에 해결 결과를 자동으로 적용합니다.

rebase에서 유용한 이유는 간단합니다.

rebase는 커밋을 하나씩 재적용하면서 충돌이 여러 번 발생할 수 있습니다.
특정 파일(예: 라우터, 설정 파일, 공통 유틸)에서 충돌 패턴이 반복되면, rerere가 바로 시간 절약으로 이어집니다.

rerere 활성화: 개인/레포 단위 설정

1) 개인 전역 설정(추천)

git config --global rerere.enabled true

이 설정을 켜면, 충돌을 해결할 때마다 기록이 자동으로 쌓입니다.

추가로 자동 업데이트도 켜두면 편합니다.

git config --global rerere.autoupdate true

rerere.autoupdate=true는 기록된 해결책이 적용 가능한 경우, 인덱스(stage)까지 더 자동으로 업데이트해주는 편의 옵션입니다.
다만 팀 규칙상 자동 stage를 싫어하는 경우도 있으니, 처음에는 enabled만 켜고 적응한 뒤 켜도 됩니다.

2) 특정 레포에서만 켜기

git config rerere.enabled true
git config rerere.autoupdate true

레포 단위 설정은 .git/config에 저장됩니다.

rerere 기록은 어디에 저장되나

기록은 기본적으로 .git/rr-cache/ 아래에 저장됩니다.

이 디렉터리는 기본적으로 버전 관리 대상이 아닙니다.
즉, 개인 PC에서 학습한 충돌 해결 기록이 다른 사람에게 자동 공유되지는 않습니다.

여기서 중요한 포인트는 “기록이 로컬에만 존재한다는 점이 오히려 안전장치가 된다”는 것입니다. 잘못된 해결을 팀 전체에 전파할 위험이 줄어듭니다.

rebase 실전 워크플로: rerere로 반복 충돌 제거하기

아래는 rerere가 가장 빛나는 전형적인 흐름입니다.

시나리오

main에서 계속 변경이 들어오는 동안, feature/long-lived 브랜치에서 공통 파일을 수정 중
rebase를 주기적으로 하며 최신 main을 따라가고 싶음

1) rebase 수행

git checkout feature/long-lived
git fetch origin
git rebase origin/main

충돌이 발생하면 평소처럼 해결합니다.

2) 충돌 해결 후 stage 및 계속 진행

# 충돌 파일 편집 후

git add path/to/conflicted-file
git rebase --continue

이때 rerere가 켜져 있으면, Git이 “충돌 전 상태”와 “내가 만든 해결 결과”를 세트로 기록합니다.

3) 다음 rebase에서 자동 해결 확인

며칠 뒤 다시 rebase를 하면, 동일한 충돌이 발생하는 순간 Git이 다음과 같은 메시지를 출력하는 것을 볼 수 있습니다.

예: Resolved '파일경로' using previous resolution. 같은 형태

그리고 충돌이 줄거나, 어떤 충돌은 아예 수동 편집 없이 지나갑니다.

rerere가 잘 먹히는 충돌/안 먹히는 충돌

잘 먹히는 경우

같은 파일에서 비슷한 라인 범위 충돌이 반복
포맷팅/정렬/리네이밍 등으로 인해 충돌 패턴이 유사하게 재발
장수 브랜치에서 주기적으로 main을 따라가는 구조

덜 먹히는 경우

충돌은 같은 파일에서 나지만 매번 맥락이 크게 달라짐(근본 로직이 계속 바뀜)
대규모 리팩터로 인해 충돌 베이스 자체가 달라져 유사도를 찾기 어려움

그럼에도 “반복 충돌이 1개라도 줄어드는 순간”부터 이득이 누적됩니다.

rerere 기록 확인과 디버깅

rerere 상태 확인

git config --get rerere.enabled
git config --get rerere.autoupdate

rerere가 적용 가능한지 수동으로 재시도

rebase나 merge 도중에 기록 적용을 다시 시도하고 싶다면 아래가 유용합니다.

git rerere

이미 충돌이 난 상태에서 git rerere를 실행하면, 적용 가능한 기록을 찾아 반영합니다.

어떤 파일이 rerere 대상인지 확인

git rerere status

기록 정리

오래된/불필요한 기록을 정리하려면:

git rerere gc

주의사항: 자동 해결은 “정답”이 아니다

rerere는 반복 작업을 줄여주지만, 자동으로 적용된 결과가 항상 비즈니스 로직의 정답은 아닙니다.

권장 습관:

자동 해결이 적용된 커밋 구간에서는 테스트를 더 신뢰할 것
특히 설정 파일, 권한/보안 관련 코드, 마이그레이션 스크립트는 자동 해결 후 반드시 리뷰할 것

이건 운영 장애 트러블슈팅과 비슷합니다. 예를 들어 네트워크/인프라 이슈에서 “증상이 사라졌다”가 “원인이 해결됐다”를 보장하지 않듯, 자동 머지도 “충돌이 사라졌다”가 “의도가 보존됐다”를 보장하지 않습니다. 장애 관점의 점검 루틴은 아래 글들도 참고할 만합니다.

팀에서 rerere를 더 잘 쓰는 운영 팁

1) 리베이스 정책과 함께 쓰면 효과가 커진다

“작게 자주 리베이스”할수록 충돌이 작은 단위로 쪼개지고, rerere가 기록을 재사용하기 쉬워집니다.
반대로 한 달에 한 번 몰아서 리베이스하면 충돌이 거대해지고, 해결 패턴이 매번 달라져 재사용률이 떨어집니다.

2) 장수 브랜치는 가능하면 줄이고, 불가피하면 `rerere`를 기본 장착한다

장수 브랜치는 충돌의 빈도와 반복성을 동시에 높입니다.
조직 문화상 장수 브랜치가 필요하다면, rerere는 사실상 필수 도구에 가깝습니다.

3) CI를 “자동 해결 검증 장치”로 삼는다

rerere가 자동으로 충돌을 풀어도, 테스트가 실패하면 그 해결은 잘못된 것입니다.
특히 타입체크, 린트, 통합 테스트를 rebase 후에 빠르게 돌릴 수 있는 구조가 중요합니다.

CI/배포 자동화 쪽은 GitHub Actions 권한/인증 문제에서 자주 막히는데, 관련해서는 아래 글이 도움이 됩니다.

GitHub Actions OIDC assume-role 실패 7분 해결법

자주 쓰는 rebase 충돌 해결 명령 모음

실전에서 rerere와 함께 가장 많이 쓰는 조합입니다.

# 1) rebase 시작
git fetch origin
git rebase origin/main

# 2) 충돌 확인
git status

# 3) rerere로 기록 적용 재시도(필요 시)
git rerere

# 4) 해결 후 stage
git add -A

# 5) 계속 진행
git rebase --continue

# 6) 중단하고 원복(너무 꼬였을 때)
git rebase --abort

결론: rerere는 “충돌 해결을 자산화”한다

rerere의 핵심 가치는 충돌 해결을 일회성 노동에서 재사용 가능한 자산으로 바꾸는 데 있습니다. 특히 rebase를 자주 하는 팀/프로젝트일수록 효과가 가파르게 커집니다.

개인은 git config --global rerere.enabled true만으로 바로 체감 가능
반복 충돌이 많은 레포에서는 rerere.autoupdate까지 켜서 흐름을 더 매끄럽게
자동 해결을 맹신하지 말고 테스트/리뷰로 의도를 검증

한 번만 제대로 세팅해두면, 앞으로의 리베이스 경험이 확실히 달라집니다.