Unable to create index.lock은 커밋 내용이 틀린 게 아니라 다른 깃 명령이 저장소를 잠갔거나 죽은 명령이 잠금 파일을 남긴 줄입니다. 프로세스를 본 뒤에만 지우고 .git/index는 건드리지 않습니다. 크론 발행, 워크트리, 에디터 깃, 한국 1인 넥스트 운영 기준. 2026년 9월 Git 공식 문서.
Unable to create index.lock은 커밋 내용이 틀린 게 아니라, 이미 다른 깃 명령이 저장소를 잠갔거나 이전 명령이 남긴 잠금 파일이 남아 있다는 뜻입니다. 그래서 메시지를 지우고 다시 커밋하기 전에, 지금 누가 그 저장소를 쓰고 있는지부터 보세요.
한국에서 넥스트를 혼자 여러 워크트리로 돌리다 보면, 크론 발행과 수동 커밋이 같은 .git을 겹쳐 이 줄이 납니다. 에디터가 백그라운드 깃을 돌리는 순간과도 겹칩니다.
파일을 바로 지우기 전에 살아 있는 깃 프로세스와 워크트리부터 맞춥니다. 근거는 git commit 문서와 깃 용어집에 있습니다.
동시에 인덱스 두 개가 쓰이지 않게 막는 파일입니다. 깃은 커밋, 머지, 스태시처럼 인덱스를 바꾸는 작업 앞에 .git/index.lock을 만들고, 끝나면 지웁니다. 작업이 중간에 죽으면 파일이 남습니다.
터미널을 강제 종료했거나, 노트북이 잠든 사이 커밋이 끊기거나, 에디터 깃 확장이 같은 저장소에서 status를 돌다가 충돌하면 흔히 남습니다. 메시지에 경로가 찍히니, 그 경로가 지금 작업 중인 저장소 루트인지부터 읽으세요.
포트 점유와 느낌이 비슷합니다. 프로세스가 자리를 안 비우면 다음 명령이 못 앉습니다. 포트 쪽은 EADDRINUSE이고, 여기서는 인덱스 잠금입니다. 코드를 고칠 자리가 아닙니다.
먼저 기억할 것 | lock를 지우는 건 마지막입니다. 다른 깃 커밋이나 크론이 살아 있으면, 지우는 순간 인덱스가 깨질 수 있습니다.
잠금을 쥔 프로세스를 먼저 찾습니다. 맥과 리눅스에선 ps aux | grep git으로 커밋, 페치, 훅이 떠 있는지 봅니다.
| 상황 | 증상 | 먼저 할 일 |
|---|---|---|
| 다른 터미널 커밋 | 한쪽은 진행, 한쪽은 lock | 끝날 때까지 대기 |
| 크론 발행 | 새벽 스크립트와 수동 커밋 겹침 | 크론 PID 확인 후 대기 |
| 에디터 깃 | 소스 트리, VS Code Git | 확장 새로고침 중지 |
| 죽은 프로세스 | ps에 git 없음, lock만 남음 | 그때만 파일 삭제 |
| 권한 | 만든 유저와 지울 유저가 다름 | 소유자 확인 |
크론이나 launchd가 같은 저장소에서 git add를 하면, 낮에 수동 커밋과 겹칩니다. 노드 권한 크론이 파일을 못 여는 줄은 노드 권한과 크론이고, 여기서는 깃 잠금만 봅니다.
잠금을 쥔 깃이 살아 있는지 보기ls -l .git/index.lock ps aux | grep -E '[g]it ' # 워크트리면 메인 .git과 별도 gitdir을 확인 git rev-parse --git-dir
깃 프로세스가 없을 때만 지웁니다. 파일이 남아 있고 ps에 git이 없으면, 이전 명령이 뒷정리를 못 한 겁니다. 그때 rm -f .git/index.lock이 맞습니다.
커밋이 진행 중이면 지우면 안 됩니다. 인덱스가 반만 쓰인 채로 열리면, 이후 커밋이 엉뚱한 스테이징을 가져갈 수 있습니다. 몇 초에서 1분 정도 기다렸다가 다시 커밋해 보세요.
권한 때문에 못 지우는 경우도 있습니다. 크론이 root로 lock를 만들었는데 낮에 일반 유저로 지우려 하면 거절됩니다. ls -l .git/index.lock의 소유자를 보고, 만든 쪽에서 지우세요. 모듈을 못 찾는 크론과 겹치면 실행 위치부터 맞춥니다. cwd 문제는 Cannot find module입니다.
프로세스가 없을 때만 lock 삭제# git 프로세스가 없는지 확인한 뒤에만 rm -f .git/index.lock git status # 인덱스가 이상하면 git reset # 필요하면 다시 add
워크트리는 작업 폴더는 달라도 gitdir를 나눕니다. 메인 저장소 lock와 워크트리 lock 경로가 다릅니다. 에러가 .git/worktrees/이름/index.lock이면 그 워크트리 쪽을 봐야 합니다.
핫픽스를 워크트리로 빼 두고 본 트리에서 커밋하면, 서로 다른 lock입니다. 같은 줄을 두 트리에서 고치면 잠금이 아니라 머지 충돌이 납니다. 워크트리 분리는 깃 워크트리 글을 보세요.
한국에서 카카오 콜백 사이트 여러 개를 한 노트북으로 발행하면, 크론이 저장소마다 순서가 아니라 동시에 깃을 만질 수 있습니다. 발행 스크립트에 저장소 단위 flock을 두면 낮 수동 커밋과 안 겹칩니다.
index 자체를 지우지 말 것 | 지울 대상은 index.lock입니다. .git/index를 지우면 스테이징이 통째로 사라집니다. 파일 이름 끝 lock만 지웠는지 한 번 더 보세요.
status가 이상하면 스테이징을 다시 잡습니다. git status에 없던 파일이 올라가 있거나, 방금 add한 파일이 빠졌으면 git reset 후 다시 add하세요.
머지 중이던 lock이면 머지 상태 파일도 남아 있을 수 있습니다. .git/MERGE_HEAD가 있으면 잠금만의 문제가 아닙니다. 머지를 이어갈지, abort할지 정한 뒤에 커밋하세요.
| 남은 파일 | 의미 | 다음 |
|---|---|---|
| index.lock만 | 죽은 잠금 | 프로세스 확인 후 삭제 |
| MERGE_HEAD | 머지 진행 중 | 이어가기 또는 abort |
| rebase-merge | 리베이스 진행 중 | continue 또는 abort |
| index 손상 | 스테이징 이상 | reset 후 다시 add |
공식 문서 다섯 곳을 기준으로 적었습니다.
내부 연계: 포트 점유, 깃 워크트리, 모듈을 찾을 수 없음, 노드 권한과 크론
인용한 동작은 2026년 9월 공개 문서 기준입니다.
다른 깃 프로세스가 없을 때만 됩니다. ps에 git 커밋이나 훅이 있으면 끝날 때까지 기다리세요. 지울 대상은 index.lock이지 .git/index가 아닙니다.
크론, 에디터 깃, 다른 터미널이 같은 저장소를 아직 만지고 있습니다. 누가 lock를 다시 만드는지 프로세스를 보세요. 발행 스크립트와 낮 작업을 겹치지 않게 순서를 나누세요.
경로가 다릅니다. 에러에 찍힌 gitdir 아래 index.lock을 봐야 합니다. 메인 .git/index.lock만 지워서는 워크트리 잠금이 안 풀립니다.
크론이 다른 유저로 lock를 만든 경우입니다. ls -l로 소유자를 보고 그 유저로 지우세요. 낮 계정으로 강제 삭제하면 다음 크론이 또 실패할 수 있습니다.
MERGE_HEAD가 있으면 머지가 아직 끝나지 않은 겁니다. lock만 지우고 커밋하면 상태가 꼬입니다. git merge --continue 또는 --abort를 먼저 정하세요.
저장소마다 동시에 git add 하지 말고, 한 저장소가 끝난 뒤 다음으로 넘어가게 하세요. 저장소 단위 flock을 두면 낮 수동 커밋과도 안 겹칩니다.
