Git rebase 중 conflict 폭발? rerere로 자동해결

서로 다른 브랜치에서 같은 파일을 오래 건드리다 보면, git rebase는 어느 순간 ‘conflict 폭발’ 상태가 됩니다. 특히 기능 브랜치를 오래 끌고 가다가 메인 브랜치 변경을 따라잡기 위해 인터랙티브 리베이스를 시작하면, 비슷한 충돌을 커밋마다 반복해서 해결하게 되죠.

이때 가장 체감이 큰 기능이 rerere(reuse recorded resolution)입니다. 이름 그대로 한 번 해결한 충돌의 해결 결과를 기록해 두었다가, 다음에 동일/유사한 충돌이 다시 나타나면 Git이 자동으로 해결안을 재적용해 줍니다.

이 글에서는 rerere가 어떤 원리로 동작하는지, rebase에서 어떻게 켜고 운영하면 좋은지, 그리고 “왜 자동 해결이 안 됐지?” 같은 실전 트러블슈팅까지 정리합니다.

> 충돌을 줄이는 운영/자동화 관점이 궁금하다면, CI에서 상태가 꼬였을 때 깨끗하게 초기화하는 전략도 함께 참고할 만합니다: GitHub Actions 캐시 충돌 시 빌드 완전 초기화 전략

rebase에서 충돌이 ‘폭발’하는 패턴

rebase는 “내 커밋을 새로운 베이스 위에 다시 쌓는” 작업입니다. 즉, 내 커밋 하나하나를 순서대로 체리픽하는 것과 유사하게 진행됩니다. 그래서 아래 상황에서 충돌이 기하급수적으로 늘어납니다.

같은 파일을 여러 커밋에서 연속으로 수정해 두었고, 메인 브랜치에서도 같은 영역이 바뀐 경우
리팩터링(파일 이동/함수명 변경) + 기능 개발이 섞여 충돌이 반복적으로 유사하게 발생하는 경우
충돌 해결을 했는데, 다음 커밋에서 또 같은 줄 근처가 충돌나서 거의 같은 해결을 다시 수행하는 경우

여기서 핵심은 “같은 충돌을 다시 만난다”입니다. rerere는 이 반복을 끊어줍니다.

rerere란? (reuse recorded resolution)

rerere는 Git이 충돌을 만났을 때:

충돌 난 파일의 **충돌 전 상태(ours/theirs + conflict hunks)**를 특징값으로 저장하고
사용자가 수동으로 해결한 뒤
그 해결 결과를 “이런 충돌이 오면 이렇게 풀어라”라는 규칙처럼 기록합니다.

그 후 동일하거나 충분히 유사한 충돌이 다시 발생하면 Git이 해당 기록을 찾아 자동으로 해결안을 적용합니다.

rerere가 특히 강한 경우

장수 브랜치(long-lived branch)에서 주기적으로 rebase/merge를 반복
큰 리팩터링 뒤에 기능 브랜치를 rebase
“충돌은 항상 같은 파일/같은 패턴”으로 나는 레포

반대로, 충돌 패턴이 매번 완전히 다르거나, 충돌이 거의 없는 팀이라면 체감이 작을 수 있습니다.

rerere 활성화: 전역/레포 단위 설정

전역으로 켜기 (추천)

git config --global rerere.enabled true

전역으로 켜면 대부분의 레포에서 바로 이득을 봅니다.

특정 레포에서만 켜기

git config rerere.enabled true

자동으로 stage까지 해주기 (선택)

rerere가 해결안을 적용한 뒤 자동으로 git add까지 해주길 원하면:

git config --global rerere.autoupdate true

장점: rebase 중 “해결됨 → add → continue” 루프가 빨라짐
주의: 자동 적용이 항상 정답은 아니므로, 팀 규칙상 반드시 diff 확인을 강제한다면 끄는 것도 방법

실전: rebase 중 rerere로 충돌 자동 해결 흐름

가장 흔한 시나리오를 그대로 따라가 보겠습니다.

1) 리베이스 시작

git fetch origin
git switch feature/my-work
git rebase origin/main

충돌이 나면 Git이 멈춥니다.

2) 첫 충돌은 수동 해결 (학습 단계)

충돌 파일을 열어 해결하고:

git status
# both modified: src/foo.py

# 해결 후
git add src/foo.py
git rebase --continue

이때 rerere가 켜져 있으면, Git은 “이 충돌의 해결 결과”를 내부적으로 기록합니다.

3) 다음 커밋에서 비슷한 충돌이 또 나면?

rebase가 다음 커밋을 적용하다가 비슷한 충돌을 만나면, rerere가 기록을 찾아 자동으로 패치합니다.

보통 콘솔에 이런 메시지가 보입니다(버전/상황에 따라 표현은 다를 수 있음).

Recorded resolution for 'path'
Resolved 'path' using previous resolution.

자동으로 해결되었더라도 반드시 diff를 확인하는 습관이 중요합니다.

git diff
# 또는
# git diff --staged

문제가 없으면 계속 진행:

git rebase --continue

rerere 상태 확인과 운영 팁

rerere 기록 확인

git rerere status

어떤 파일/충돌이 rerere 적용 대상인지(또는 적용되었는지) 확인할 때 유용합니다.

rerere로 적용된 해결안 확인

git rerere diff

rerere가 제안/적용한 변경을 확인할 수 있습니다.

“충돌 해결 학습”을 더 확실히 하고 싶다면

충돌이 난 직후 무작정 고치기보다, 아래 순서가 rerere 품질을 높입니다.

충돌 난 파일에서 “의도한 최종 형태”를 명확히 결정
테스트/빌드로 검증
git add → rebase --continue

rerere는 “내가 최종적으로 저장한 해결 결과”를 학습하므로, 대충 해결하고 넘어가면 그 대충이 다음에도 반복됩니다.

자주 겪는 문제: 왜 rerere가 자동 해결을 못 했을까?

1) rerere가 아예 꺼져 있었다

git config --get rerere.enabled

값이 없거나 false면 켜주세요.

git config --global rerere.enabled true

2) 충돌 패턴이 ‘동일/유사’하지 않다

rerere는 “완전히 같은 파일”이 아니라 “충돌 hunk의 형태”를 기준으로 재적용합니다. 하지만 다음과 같은 경우 유사도가 깨져서 매칭이 실패할 수 있습니다.

리팩터링으로 코드 위치가 크게 이동
공백/포맷팅 대규모 변경으로 hunk 경계가 달라짐
충돌의 양쪽(ours/theirs)이 이전과 다른 형태로 바뀜

이럴 때는 rerere가 일부만 적용하거나, 아예 적용하지 못합니다.

3) 자동 적용은 됐는데 결과가 이상하다

이 경우가 더 위험합니다. rerere는 “과거에 맞았던 해결”을 가져오지만, 지금도 맞는지는 보장하지 않습니다.

권장 체크리스트:

git diff로 변경 확인
최소 단위 테스트 실행
도메인 규칙/스펙 변경이 있었는지 확인

프로덕션 장애처럼 “한 번의 자동화가 큰 사고로 이어지는” 영역에서는, 자동 적용 후 검증을 강화하는 편이 안전합니다. (운영 관점의 트러블슈팅 글로는 Argo CD Sync 실패 - OutOfSync·Degraded 해결법 같은 글도 같이 보면 좋습니다.)

rerere와 함께 쓰면 좋은 rebase 습관

1) 커밋을 의미 단위로 쪼개기

커밋이 “리팩터링 + 기능 + 포맷팅”이 섞여 있으면 충돌도 복잡해지고 rerere의 재사용 가치도 떨어집니다.

리팩터링 커밋
기능 커밋
포맷팅 커밋

을 분리하면 충돌 패턴이 더 명확해져 rerere가 더 잘 먹힙니다.

2) `rebase --rebase-merges`는 신중히

머지 커밋을 보존한 채 rebase하면 히스토리는 유지되지만 충돌 지점이 늘어날 수 있습니다. rerere가 도움은 되지만, 팀의 브랜치 전략과 함께 결정하세요.

3) 충돌이 반복되는 파일은 구조적 개선 고려

한 파일에 너무 많은 책임이 몰려 있다면 모듈 분리
공통 설정 파일(예: YAML, CI 설정)이 충돌의 진원지라면 템플릿/분할

이런 구조 개선은 rerere보다 근본적인 해결책입니다. CI 파이프라인 파일이 자주 충돌한다면 캐시/초기화 전략까지 포함해 운영을 다듬는 게 좋습니다: GitHub Actions 캐시 충돌 시 빌드 완전 초기화 전략

팀 적용 가이드: “개인 로컬 기능”을 어떻게 운영할까?

rerere는 기본적으로 개인 로컬 저장소에 기록이 쌓이는 기능입니다. 그래서 팀 차원의 룰은 보통 이렇게 갑니다.

팀 규칙: rerere 사용은 권장(강제 X)
PR 규칙: 자동 해결 여부와 무관하게 테스트 통과/리뷰 통과는 필수
온보딩 문서: rerere.enabled, rerere.autoupdate 설정 가이드 제공

만약 충돌 해결 노하우를 조직 자산으로 공유하고 싶다면, rerere 자체를 공유하기보다는 “충돌이 잦은 파일의 변경 규칙”이나 “리팩터링 순서” 같은 프로세스를 문서화하는 편이 재현성과 안전성이 높습니다.

마무리

git rebase에서 충돌이 폭발하는 진짜 고통은 “어려운 충돌 1번”이 아니라 “비슷한 충돌 20번”입니다. rerere는 이 반복을 자동화해, 리베이스를 노가다에서 절차로 바꿔 줍니다.

한 번 해결한 충돌을 기록하고
이후 동일/유사 충돌을 자동 적용하며
검증만 잘 붙이면 rebase 효율이 크게 올라갑니다.

오늘 바로 아래 두 줄부터 켜두면, 다음 충돌 시즌에 시간을 아낄 수 있습니다.

git config --global rerere.enabled true
git config --global rerere.autoupdate true