Git unrelated histories 해결: 원격 주소와 공통 조상부터 확인

직접 생성한 개념 이미지입니다. 실제 서비스 화면이나 구축·성능 시험 결과가 아닙니다.

refusing to merge unrelated histories는 두 이력의 공통 조상을 찾지 못한 상황에서 나타날 수 있습니다. 먼저 저장소·원격 주소·비교 대상이 맞는지 확인하세요. 의도적으로 독립된 이력을 합치는 경우에만 --allow-unrelated-histories를 검토하고, 원본 보존과 충돌 검토를 먼저 준비합니다.

원인: 같은 파일이 있어도 같은 커밋 이력은 아니다

로컬과 원격에서 각각 새 저장소를 초기화했거나 다른 저장소를 연결하면 파일 이름이 비슷해도 이력이 독립적일 수 있습니다. 오류를 없애기 위해 곧바로 강제 푸시하거나 .git을 삭제하면 보존해야 할 기록을 잃을 수 있습니다.

상태	우선 확인	피할 조치
원격 주소 불일치	저장소 선택	무조건 병합
이력 제한 가능	clone 범위	독립 이력 단정
독립 이력 통합 승인	원본·시험 브랜치	즉시 공유 푸시
미커밋 변경 존재	변경 보존	정리·삭제

1. 읽기 전용으로 대상부터 확인한다

git status --short
git branch --show-current
git remote -v
git log --oneline --decorate -8

작업 디렉터리와 브랜치가 맞는지 확인합니다. remote 출력에 인증정보가 들어간 URL을 사용 중이라면 그대로 공유하지 마세요. origin/main은 관습적인 예시일 뿐 실제 저장소의 기본 브랜치가 항상 main인 것은 아닙니다.

원격 추적 참조가 오래되었으면 승인된 네트워크 접근 범위에서 갱신한 뒤 비교해야 합니다. shallow clone처럼 이력이 제한된 환경도 확인합니다. 공통 조상이 보이지 않는다는 사실만으로 원래부터 독립된 저장소였다고 단정하지 않습니다.

2. 실제 비교 참조의 공통 조상을 확인한다

git merge-base HEAD origin/main

예시 참조가 존재하고 올바른 대상을 가리키는지 먼저 확인하세요. 출력과 종료 상태를 함께 보고, 이력이 충분히 확보됐는지도 확인합니다. 잘못 연결한 저장소라면 병합을 허용하는 것이 해결책이 아닙니다. 원하는 저장소를 별도 경로에서 확인하고 현재 작업은 보존합니다.

3. 독립 이력 통합이 정말 필요한 경우

두 이력의 출처와 통합 목적이 확인된 경우에만 검토용 브랜치에서 병합을 준비합니다. 원본 커밋 참조와 미커밋 파일을 별도로 보존하고 깨끗한 작업 상태에서 진행하세요. 공식 문서의 --allow-unrelated-histories는 기본 거절을 바꾸는 옵션이지 내용이 맞다는 인증이 아닙니다.

병합 결과를 커밋 전에 검사하려면 --no-commit과 --no-ff의 동작도 확인합니다. 충돌 파일뿐 아니라 자동 병합된 설정·잠금 파일·배포 경로도 검토해야 합니다. 검토가 끝나기 전 공유 브랜치에 푸시하지 않습니다.

확인 방법과 주의

최종 파일 차이, 필요한 두 이력의 보존, 빌드·테스트 결과를 각각 확인합니다. 취소에는 git merge --abort가 있지만 병합 전부터 미커밋 변경이 있었다면 원상 복원이 완전하지 않을 수 있습니다. 그래서 사전 보존이 중요합니다. 이 글은 실제 저장소를 병합하거나 명령을 실행한 시험 기록이 아닙니다.

FAQ

파일이 같으면 같은 이력 아닌가요? 파일 내용과 커밋 연결 관계는 다릅니다.

허용 옵션을 항상 설정해도 되나요? 잘못된 저장소 통합을 놓칠 수 있으므로 해당 병합의 목적을 확인합니다.

강제 푸시로 해결하나요? 원격 이력을 덮는 동작은 이 진단의 기본 해결책이 아닙니다.

공식 출처와 관련 글

자료 확인일: 2026년 10월 19일. 공식 문서 기반 설명이며 실제 서비스·명령 실행 시험은 수행하지 않았습니다. 설치 버전과 리전·지원 범위는 적용 전에 확인하세요.

git merge 공식 문서

공통 조상 확인

관련 글: Git 저장소 소유권 오류와 구분하기

적용 전 원본 설정을 보존하고 승인된 시험 범위에서 결과를 확인하세요.