한 줄 요약: AI에게 “오늘 작업 커밋해줘”라고 했더니, 이미 GitHub Desktop이 몰래 커밋·푸시를 해놓은 상태였다. 두 도구가 같은 저장소를 동시에 건드리면서 git이 “잠금(lock)” 오류를 냈고, 원인을 찾아 순서대로 풀었다.
이런 분께 도움이 돼요: AI(터미널)로 배포 작업을 하면서, 동시에 GitHub Desktop 같은 GUI 프로그램도 같이 쓰는 분. Unable to create '.git/index.lock' 같은 오류를 만난 분.
Before — 뭐가 이상했나
오늘 작업(학습일지·사례글·프로젝트 페이지)을 다 만든 뒤, AI에게 “커밋으로 저장해줘”라고 요청했다. 그런데 git status를 확인해보니 이상했다 — 내가 요청하기도 전에, 이미 45c636f라는 낯선 커밋이 저장소에 올라가 있었고, 그 안에 오늘 만든 파일이 전부 들어있었다. “나는 저장한 적이 없는데 왜 이미 저장돼 있지?”
어떻게 풀었나
1. 진짜 상태부터 확인 (짐작하지 않기)
AI가 로컬 git 로그만 보지 않고, gh api repos/.../commits/master로 GitHub 서버에 직접 물어봐서 실제로 그 커밋이 GitHub에도 올라가 있는지 확인했다. 결과: 로컬과 GitHub 둘 다 이미 그 커밋 상태였다. 즉 “로컬에만 있고 GitHub엔 안 올라갔겠지”라는 짐작이 틀렸던 것.
2. 안 지워진 변경 하나 발견 → 되돌리려다 막힘
살펴보니 landing.md에 누군가 장난스럽게 바꿔놓은 인사말 한 줄이 커밋 안 되고 남아있었다. 이걸 원래대로 되돌리려고 git restore를 실행했는데, 이런 오류가 떴다:
fatal: Unable to create '.../.git/index.lock': File exists.
Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again.
3. 범인 찾기
AI가 실행 중인 프로그램 목록(tasklist)을 확인해서, 내 컴퓨터에 GitHub Desktop이 켜져 있는 걸 찾아냈다. 이게 배경에서 같은 저장소에 자동으로 커밋·푸시를 하고 있었던 것 — 아까 발견한 “낯선 커밋”의 정체였다.
AI가 바로 잠금 파일을 지우지 않고, 먼저 “GitHub Desktop이 지금 뭔가 하는 중일 수도 있으니, 직접 닫아주실 수 있나요?”라고 물어봤다. 잠금 파일을 함부로 지우면 그 프로그램이 작업하던 도중에 저장소가 꼬일 수 있어서였다.
4. 프로그램 종료 확인 → 그래도 안 풀림
GitHub Desktop을 껐다. 그런데 다시 시도해도 같은 오류가 났다. tasklist로 다시 확인해보니 프로세스는 완전히 꺼져 있었다 — 즉 잠금 파일이 프로그램이 죽으면서 청소가 안 되고 남아있는 찌꺼기(stale lock)였다. 프로세스가 없는 걸 다시 확인한 뒤에야 안전하게 잠금 파일을 지우고 landing.md를 되돌렸다.
5. 커밋할 때 또 한 번
마지막으로 남은 설정 파일을 커밋하려는데, 이번엔 HEAD.lock 오류가 또 났다. 같은 원인(아까 그 배경 작업의 잔여물)이라 판단하고, 같은 방식(프로세스 확인 → 잠금 파일 제거)으로 바로 풀었다.
fatal: cannot lock ref 'HEAD': Unable to create '.../.git/HEAD.lock': File exists.
After — 결과
- 로컬 · GitHub · 배포된 사이트 세 곳이 모두 같은 상태로 정리됨.
- 커밋
ec0dc28까지 정상적으로 push 완료. - 이제부터는 GitHub Desktop과 AI(터미널) 중 하나로만 커밋하기로 정함 — 같은 저장소를 두 도구로 동시에 만지지 않기.
배운 것 / 재사용 자산
- 알아둘 점: git은 커밋 등 작업 중에
.git/index.lock,.git/HEAD.lock같은 임시 잠금 파일을 만든다. 정상적으로는 작업이 끝나면 자동으로 사라지는데, 프로그램이 비정상 종료되면 이 파일이 안 지워지고 남아서 다음 작업을 막을 수 있다. - 오류를 만나면 이 순서로: ① 지금 이 저장소를 건드리는 다른 프로그램(GitHub Desktop, 다른 터미널, 편집기 등)이 실행 중인지 확인 → ② 있으면 종료 → ③ 그래도 오류가 남으면, 프로세스가 진짜 없는지 다시 확인한 뒤에만 잠금 파일을 지운다. (프로세스가 살아있는데 지우면 저장소가 꼬일 수 있으니 순서를 건너뛰지 않는 게 중요하다.)
- 재사용 프롬프트: “git 오류가 나는데, 지금 이 저장소를 다른 프로그램이 건드리고 있는지 먼저 확인하고, 잠금 파일 문제면 안전하게 해결해줘.”
- 꿀팁: “저장했다”는 말을 그대로 믿지 말고,
git status나 GitHub 저장소 화면에서 실제로 반영됐는지 눈으로 한 번 더 확인하는 습관이 도움이 된다.
(Tip: 여기에 오류 메시지 캡처나 GitHub Desktop 실행 화면을 넣으면 좋아요)