fatal: refusing to merge unrelated histories는 공통 조상 커밋이 없어 깃이 머지를 거절한 줄입니다. 원격 URL이 맞을 때만 git pull origin main --allow-unrelated-histories로 잇습니다. 갈라진 브랜치, 커밋 전 덮어쓰기와는 다릅니다. Git, 리드미, 깃허브, 한국 1인 개발. 2026년 10월 문서.
fatal: refusing to merge unrelated histories는 두 브랜치가 싸운 게 아니라, 공통 조상 커밋이 없어서 깃이 합치기를 거절한 줄입니다. 원격 주소가 맞으면 허용 플래그로 한 번만 잇고, 주소가 틀리면 그 플래그를 쓰지 마세요.
로컬에서 저장소를 만들고 첫 커밋을 한 뒤, 리드미가 있는 깃허브 저장소를 당기면 이 문장이 납니다. 둘 다 루트 커밋이 따로 있어서 맞출 기준이 없습니다. 한국에서 새 원격에 리드미를 켜 두면 자주 만납니다.
머지 문서는 공통 조상이 없으면 기본으로 거절하고, 일부러 합칠 때만 허용 플래그를 쓰라고 적습니다. 이 기본값은 2016년 6월의 2.9부터입니다. 근거는 깃 머지 문서입니다.
깃은 머지할 때 두 끝이 공유하는 조상 커밋을 찾습니다. 그 커밋이 없으면 어느 쪽이 변경인지 계산할 기준이 없습니다. 2.9 이전에는 이런 합치기가 조용히 진행되어, 잘못된 원격을 당기면 전혀 다른 프로젝트가 한 트리에 붙었습니다. 그래서 지금은 확인 없이는 거절합니다.
자주 만나는 장면은 두 가지입니다. 첫째, 로컬에서 저장소를 만들고 커밋한 다음 깃허브에서 리드미와 함께 만든 원격의 main을 당기는 경우. 둘째, 빈 폴더가 아니라 이미 커밋이 있는 다른 프로젝트를 같은 폴더에 원격으로 추가한 경우. 한쪽이라도 커밋이 0이면 이 거절은 나지 않고, 그 빈 쪽이 있는 쪽으로 맞춰집니다.
플래그는 안전장치가 아닙니다. 서로 다른 두 제품을 한 저장소로 붙이는 명령입니다. 원격 URL을 확인하기 전에 쓰면, 리드미 충돌보다 큰 트리가 한 커밋에 들어옵니다.
순서는 주소, 페치, 공통 조상입니다. git remote -v의 URL이 올리려는 저장소인지 먼저 읽습니다. 그다음 git fetch origin으로 원격 커밋을 받고, git merge-base HEAD origin/main을 실행합니다. 공통 조상이 있으면 해시가 찍히고, 없으면 종료 코드 1이며 해시는 없습니다. 해시가 있는데도 이 거절 문장이 보이면 브랜치 이름을 잘못 본 것입니다.
조상이 없고 URL이 맞을 때만 pull에 플래그를 붙입니다. 리드미를 양쪽이 만들었으면 충돌이 납니다. 어느 쪽 문장을 남길지 고른 뒤 커밋합니다. 충돌 마커를 남긴 채 푸시하지 마세요.
| 확인 | 명령 | 보고 결정할 것 |
|---|---|---|
| 원격 주소 | git remote -v | 올리려는 저장소인가 |
| 원격 커밋 | git fetch origin | origin/main이 생겼는가 |
| 공통 조상 | git merge-base HEAD origin/main | 해시가 없으면 무관한 히스토리 |
| 잇기 | pull --allow-unrelated-histories | 리드미 충돌만 고친다 |
주소가 맞을 때만 두 히스토리를 잇는다git remote -v git fetch origin git merge-base HEAD origin/main git pull origin main --allow-unrelated-histories git status
같은 저장소에서 로컬 main과 원격 main이 각각 앞으로 나가면, 거절 문장은 공통 조상이 없다는 뜻이 아닙니다. 조상은 있고 fast-forward만 안 됩니다. 그때 --allow-unrelated-histories를 붙이면 이미 한 가족인 커밋을 또 다른 뿌리로 붙입니다.
커밋이 브랜치에 안 붙은 상태는 detached HEAD입니다. 이름을 붙여 브랜치를 만들 문제이지, 원격 리드미와 루트가 두 개인 문제가 아닙니다. 당기기 전에 작업 트리의 수정 때문에 overwritten by merge가 나오면, 커밋되지 않은 파일이 원인입니다. stash나 restore로 작업 트리를 비운 뒤에야 히스토리 질문을 만납니다.
| 문장 | 의미 | 먼저 할 일 |
|---|---|---|
| unrelated histories | 공통 조상 커밋이 없음 | URL 확인 후 플래그 1회 |
| divergent branches | 조상은 있고 양쪽이 앞섬 | rebase 또는 merge, 플래그 아님 |
| detached HEAD | 커밋이 브랜치에 안 붙음 | switch -c로 이름 |
| overwritten by merge | 커밋 전 수정이 같은 파일 | stash 또는 restore |
URL이 다른 조직의 저장소를 가리키면 플래그로 잇지 않습니다. git remote remove origin으로 주소를 지우고 올바른 URL을 다시 추가합니다. 이미 플래그 머지를 했다면 그 머지 커밋을 푸시하기 전에 git log --oneline --graph -15로 뿌리 두 개가 의도한 것인지 봅니다.
원격에 자동 생성된 리드미 한 커밋만 있고, 그 문장도 필요 없다면 히스토리를 잇는 대신 원격 저장소를 리드미 없이 다시 만드는 편이 그래프가 단순합니다. 이미 이슈와 풀 리퀘스트가 있으면 저장소를 지우지 말고 플래그 머지로 잇습니다. 강제 푸시는 원격의 그 리드미 커밋을 버리므로, 혼자만 쓰는 빈 원격이라는 확신이 있을 때만 별도 판단입니다. 이 글의 기본 경로는 플래그 한 번과 충돌 해결입니다.
다음부터는 순서를 바꿉니다. 깃허브에서 빈 저장소를 만들거나, 리드미가 있는 저장소를 먼저 git clone한 뒤 파일을 넣습니다. 로컬 git init과 원격 리드미를 각각 만들면 루트가 두 개가 됩니다. 회사 폴더와 개인 폴더를 같은 원격에 처음 붙일 때도 URL을 두 번 읽습니다.
그래프에서 뿌리가 둘인지 본다git log --oneline --graph --all -15 git status
연관 글은 분리된 헤드, 커밋 전 수정이 머지를 막는 줄, 포트가 이미 열린 줄입니다. 세 번째는 깃이 아니지만, 로컬이 막힌 자리와 히스토리가 막힌 자리를 같이 보면 순서가 갈립니다.
인용한 기본값은 2026년 10월 6일 깃 문서 기준입니다. 2.9는 2016년 6월 릴리스입니다.
원격에 리드미 커밋이 있고 로컬에도 첫 커밋이 있으면 공통 조상이 없습니다. URL을 확인한 뒤 git pull origin main --allow-unrelated-histories로 한 번 잇고, 리드미 충돌만 고칩니다.
깃 2.9부터 공통 조상이 없는 머지를 기본으로 거절합니다. 잘못된 원격을 조용히 합치던 동작을 막은 것입니다. 버전을 내리기보다 조상이 정말 없는지 확인하세요.
붙이지 않습니다. 갈라진 브랜치는 공통 조상이 있고 양쪽이 앞으로 나간 상태입니다. rebase나 일반 merge로 맞춥니다. unrelated histories 문장이 아니면 이 플래그는 다른 문제입니다.
그건 overwritten by merge 쪽입니다. 커밋하지 않은 수정이 들어오려는 파일과 겹칩니다. stash나 restore로 작업 트리를 비운 다음에 히스토리를 보세요.
원격에 지킬 커밋이 리드미 하나뿐이고 혼자 쓰는 저장소라는 확신이 있을 때의 별도 판단입니다. 이슈나 다른 커밋이 있으면 플래그 머지로 잇는 쪽이 그 기록을 남깁니다.
리드미가 있는 원격은 먼저 clone한 뒤 파일을 넣습니다. 로컬 init과 원격 리드미를 각각 만들면 루트 커밋이 두 개가 됩니다.
unrelated histories는 공통 조상 커밋이 없어 깃이 합치기를 거절한다는 뜻입니다. 원격 주소를 읽고 merge-base가 비었을 때만 플래그를 한 번 쓰세요. 갈라진 pull이나 커밋 전 수정과는 명령이 다릅니다. 관련 글: 분리된 헤드, 머지 전 작업 트리, 모듈을 못 찾는 줄.
