git add -A가 PR 세 개에 옆 글을 섞어 넣은 일

2026년 10월 6일Importants Studio

AI가 쓴 글이 여러 브랜치의 PR로 올라오면, 각 브랜치에서 파일을 꺼내 로컬에 모아 읽게 됩니다. 이번에도 검증하려고 원격 브랜치의 파일을 현재 작업 트리로 가져왔습니다.

문제는 그다음이었죠. 남아 있던 파일을 나중에 다른 브랜치에서 git add -A로 커밋했고, PR 세 개가 자기 글 외에 다른 브랜치의 글까지 품게 됐는데, 머지 직전 기계 검사에서 같은 파일명이 두 번 찍힌 것을 보고서야 알았습니다.

먼저 결론부터

브랜치의 파일 내용을 확인할 때는 git checkout origin/<브랜치> -- <파일> 대신 git show <ref>:<경로>를 썼습니다. 표준출력만 보므로 작업 트리와 스테이징 영역이 바뀌지 않습니다.

git show origin/<브랜치>:<파일 경로>

git checkout origin/<브랜치> -- <파일>은 파일을 작업 트리에 꺼내는 데서 끝나지 않고 스테이징까지 합니다.
HEAD에 없는 새 파일은 git checkout HEAD -- <파일>로 되돌아가지 않았습니다. 실패한 뒤에도 스테이징된 파일은 남았습니다.
커밋할 때는 git add -A 대신 변경하려는 글 파일을 명시했습니다.

git add <글 파일 경로>

머지 전 검사에서는 브랜치별 글 파일 수가 1인지 함께 셌습니다. 이번에는 같은 파일명이 두 번 나온 것이 출발점이었습니다.
zsh에서는 git show "origin/br:content/..."가 :c를 히스토리 수정자로 읽어 실패했습니다. 먼저 아래 설정을 적용했습니다.

set +H

처음에는 원격 브랜치의 파일을 현재 브랜치로 가져오는 명령을 썼습니다.

git checkout origin/<브랜치> -- <파일>

이 명령은 파일을 확인하기에는 바로 결과가 보여 편했지만, 파일 내용만 읽는 동작이 아니었습니다. 원격 브랜치에서 가져온 파일이 작업 트리에 생기고, 동시에 스테이징 영역에도 올라갔거든요.

읽기가 끝난 뒤에는 아래 명령으로 원래대로 돌릴 생각이었습니다.

git checkout HEAD -- <파일>

그런데 새 글은 현재 HEAD에 없었습니다. 글은 확인하려고 꺼낸 원격 브랜치에만 있었고, 현재 브랜치에는 아직 추가되지 않은 파일이었으니, HEAD에서 그 경로를 찾을 수 없다는 오류가 났습니다.

오류만 남았습니다.

명령이 실패했으니 파일도 사라졌을 것이라 생각하기 쉬웠죠. 그렇지 않았습니다. 작업 트리에 꺼낸 파일과 스테이징된 상태가 그대로 남았고, 되돌리는 명령이 실패한 뒤에도 남은 이 스테이징이 뒤의 문제로 이어졌습니다.

나중에 다른 브랜치에서 커밋할 때 git add -A를 썼습니다.

하지만 git add -A는 변경의 출처를 구분하지 않습니다. 이전에 다른 브랜치에서 꺼내 놓고 남겨 둔 파일도, 지금 작성한 글도 모두 커밋 대상이 됐죠.

그 결과 PR 세 개가 옆 브랜치의 글을 함께 갖게 됐고, 그대로 머지했다면 PR 하나가 글 2편을 올릴 상황이었습니다. 파일 하나를 읽으려고 했던 작업이 커밋 범위까지 번진 셈입니다.

이후에는 추가할 파일을 경로로 적어서, 글 하나를 올리는 브랜치라면 그 글 파일만 git add에 넣었죠. 작업 트리에 남은 파일이 있더라도 지정한 파일만 커밋에 들어갑니다.

문제를 알아챈 곳은 머지 직전 검사였습니다. 브랜치별로 글 파일 수를 세는 과정에서 같은 파일명이 두 번 나왔는데, 그 두 줄을 단서로 따라 가 보니 다른 브랜치의 글이 PR 에 들어 있더라고요.

고친 뒤에는 브랜치마다 글 파일이 1개인지 확인했고, 이 검사는 내용의 품질을 보는 단계와 별개로 남겼습니다. 글이 하나여야 하는 PR에서 파일 수가 늘어나면, 작성 과정이 아니라 작업 트리의 잔여물을 먼저 의심하게 됩니다.

파일 내용을 읽는 목적이라면 이제 git show만 씁니다.

git show origin/<브랜치>:<파일 경로>

출력이 터미널로만 나오므로 현재 브랜치의 파일도, 인덱스도 바뀌지 않고, 여러 브랜치의 글을 비교할 때도 파일을 꺼냈다가 지우는 과정이 없어졌습니다.

zsh에서는 이 명령에도 한 번 걸렸습니다. 처음에는 경로 전체를 큰따옴표로 감쌌는데도 origin/br:content/...의 :c가 히스토리 수정자로 해석됐거든요. Git이 경로를 읽기 전에 셸에서 실패한 경우였죠.

그때는 아래 명령을 먼저 실행했습니다.

set +H

이후 같은 git show 명령이 실행됐습니다. 원격 참조와 파일 경로를 콜론으로 잇는 Git 문법이 zsh의 히스토리 문법과 만난 자리였습니다.

이번 일에서 남은 규칙은 두 가지입니다. 다른 브랜치의 글은 작업 트리로 가져오지 않고 표준출력으로 읽고, 커밋에는 파일 경로를 적습니다.

그리고 머지 전에는 브랜치별 글 파일 수를 다시 봅니다. 같은 파일명이 두 번 찍힌 짧은 검사 출력 덕분에 PR 세 개에 잘못 들어간 변경을 막을 수 있었습니다.