Git 파일 무시 방법 4가지 — .gitignore부터 skip-worktree까지

Git에서 파일을 워킹 디렉토리에 둔 채 추적만 멈추거나 커밋에서 제외하는 방법은 .gitignore 하나가 아닙니다. 이 글은 한국 개발자가 자주 쓰는 네 가지 무시 메커니즘과, 회사·개인 저장소를 같은 노트북에서 함께 다룰 때 유용한 includeIf 패턴까지 공식 문서 기준으로 정리합니다.

본 가이드는 2026년 6월 기준 Git 공식 문서를 따릅니다. macOS, Linux, WSL 환경에 동일하게 적용됩니다. 정리의 출발점은 GeekNews에서 큐레이션된 "Git에서 파일을 무시하는 방법은 .gitignore만이 아님" 토픽이며, 원문은 André Laszlo의 Project-level git config 글입니다.

gitignore 그 너머 — Git 파일 무시의 네 가지 층위

Git이 파일을 제외하는 규칙은 적용 범위에 따라 크게 세 층위로 나뉩니다. Git gitignore 공식 문서 기준으로 정리하면 다음과 같습니다.

• 저장소 공유 규칙 — 저장소에 커밋되는 .gitignore 파일
• 저장소 로컬 규칙 — 커밋되지 않는 .git/info/exclude
• 사용자 전역 규칙 — core.excludesfile로 지정한 사용자 홈의 ignore 파일

여기에 더해 이미 트래킹된 파일에는 git update-index의 --assume-unchanged와 --skip-worktree 플래그가 별도로 동작합니다. 네 가지를 한 묶음으로 두지 않으면 "왜 .gitignore에 넣어도 변경분이 계속 잡히지?"라는 질문에 답하기 어렵습니다.

첫 번째 층위: 팀 공유의 .gitignore

저장소 루트의 .gitignore는 가장 흔히 쓰이는 무시 규칙입니다. 파일이 저장소에 커밋되기 때문에 팀 구성원 모두에게 동일하게 적용됩니다. node_modules, build 산출물처럼 모든 협업자가 동일하게 제외해야 하는 파일을 두는 자리입니다.

한 가지 자주 놓치는 점은 적용 범위입니다. .gitignore는 아직 트래킹되지 않은 파일에만 작용합니다. 이미 git add로 인덱스에 들어간 파일은 .gitignore에 추가해도 자동으로 빠지지 않으며, git rm --cached <파일>로 인덱스에서 명시적으로 제거해야 효과가 발생합니다.

두 번째 층위: 저장소별 로컬 무시 .git/info/exclude

로컬 작업 디렉토리에만 두고 싶은 무시 규칙은 .git/info/exclude에 작성합니다. 이 파일은 .git 디렉토리 내부에 위치하므로 커밋되지 않으며, 본인 환경에서만 적용됩니다.

# 예: 개인 IDE 설정 디렉토리 로컬 제외
echo ".idea/" >> .git/info/exclude

다른 팀원에게 영향을 주지 않으면서 본인 작업 환경 파일(에디터 설정, 임시 노트 등)을 분리할 때 유용합니다. 다만 다른 머신에서 같은 저장소를 클론하면 해당 규칙이 따라가지 않는다는 점은 기억해야 합니다.

세 번째 층위: 사용자 글로벌 core.excludesfile

여러 저장소에서 공통으로 무시하고 싶은 파일이 있을 때는 사용자 전역 ignore 파일을 지정합니다. Git 공식 문서 기준으로 XDG 규약에 따라 기본 경로는 ~/.config/git/ignore이며, 명시적으로 지정하려면 core.excludesfile 옵션을 설정합니다.

git config --global core.excludesfile ~/.gitignore_global
echo ".DS_Store" >> ~/.gitignore_global
echo "*.swp" >> ~/.gitignore_global

OS가 강제로 만드는 파일(.DS_Store, Thumbs.db), Vim swap, 에디터별 임시 파일처럼 어떤 저장소에서든 절대 커밋하고 싶지 않은 항목을 모아 두는 자리입니다.

트래킹된 파일은 다르다: assume-unchanged와 skip-worktree

이미 git add 되어 트래킹 중인 파일은 .gitignore에 추가해도 안 사라진다는 사실을 알면서도, 인덱스에서 빼지 않고 변경만 무시하고 싶을 때가 있습니다. 대표적으로 설정 템플릿을 공통으로 두되 로컬 값을 수정하는 경우입니다.

이때 두 가지 인덱스 플래그가 자주 거론됩니다. git update-index 공식 문서는 두 옵션의 의도가 서로 다르다고 명시합니다.

• --assume-unchanged — Git에 "이 파일은 변하지 않는다"고 알리는 성능 힌트. stat 호출을 줄이기 위한 용도이며, 사용자가 약속을 어겨도 Git이 보호하지 않습니다.
• --skip-worktree — 사용자의 로컬 변경을 보존하기 위한 의도된 무시. git checkout, git pull 등이 워크트리 파일을 덮어쓰지 않도록 보호합니다.

로컬에서 자주 손대는 설정 파일은 --skip-worktree가 안전합니다. --assume-unchanged는 본래 slow 파일시스템 성능 최적화 용도이며, 무시 목적으로 쓰면 git checkout 시 손쉽게 덮어쓰일 수 있다는 점은 별도로 기억해 둘 필요가 있습니다.

# 로컬 변경 보존 (권장)
git update-index --skip-worktree config/local.yml

# 해제
git update-index --no-skip-worktree config/local.yml

현재 어떤 파일에 플래그가 켜져 있는지는 git ls-files -v로 확인할 수 있습니다. skip-worktree가 켜진 파일은 출력 첫 문자가 S로 표시됩니다.

디렉토리 단위 분기: includeIf로 작업과 개인을 분리

한국 개발자는 회사 GitLab 저장소와 개인 GitHub 저장소를 같은 노트북에서 다루는 경우가 흔합니다. 커밋 user.email을 매번 저장소마다 설정하는 대신, git-config 공식 문서의 조건부 include 디렉티브를 활용하면 디렉토리 단위로 설정을 갈아 끼울 수 있습니다.

# ~/.gitconfig
[user]
    email = personal@example.com
    name = Honggildong

[includeIf "gitdir:~/work/"]
    path = ~/work/.gitconfig

# ~/work/.gitconfig
[user]
    email = honggildong@company.com

[core]
    excludesfile = ~/work/.gitignore

~/work/ 하위에 있는 모든 저장소가 자동으로 회사 이메일과 회사 전용 ignore 파일을 사용합니다. 원문 글에서도 이 패턴이 핵심으로 소개됩니다. includeIf는 Git 2.13에서 도입되었으며, 디렉토리 조건 외에 onbranch:로 브랜치별 분기까지 지원합니다.

어떤 방법을 언제 쓸지: 판단 가이드

네 가지 메커니즘은 적용 범위와 영속성이 다릅니다. 다음 기준으로 선택하면 실수가 줄어듭니다.

• 팀 전원이 적용해야 하는 무시 → 저장소 루트의 .gitignore를 커밋합니다.
• 본인만의 저장소별 임시 무시 → .git/info/exclude에 작성합니다.
• 모든 저장소에 공통 적용 → core.excludesfile로 사용자 전역 ignore를 만듭니다.
• 이미 트래킹된 파일의 로컬 변경 보존 → --skip-worktree를 사용합니다.
• 회사·개인 등 디렉토리별 user.email과 ignore 분기 → includeIf로 묶습니다.

실수가 가장 잦은 영역은 두 가지입니다. (a) 이미 트래킹된 파일을 .gitignore에 추가하고 효과가 없다고 오해하는 경우, (b) --assume-unchanged를 로컬 보존 목적으로 사용해 git pull 후 변경이 손실되는 경우. 두 사례 모두 위 가이드의 분류로 회피할 수 있습니다.

관련 글

Git 워크플로와 보안·도구 운영을 함께 살피면 무시 규칙의 맥락이 더 분명해집니다. 다음 글이 함께 읽어볼 만합니다.

• AI 에이전트가 PR 리뷰에 개입하는 시대의 운영 체크리스트: Fedora를 속인 자율 AI 에이전트 — 한국 백엔드 팀 PR 리뷰 체크리스트
• 민감한 설정·키 파일을 실수로 커밋하지 않기 위한 보안 관점: LinkedIn 가짜 채용으로 위장한 npm 백도어 — 한국 개발자 방어 가이드
• CLI 도구 전환과 환경 설정 이관 노하우: Gemini CLI 종료 D-1: Antigravity CLI 전환 체크리스트

---

📌 함께 보시면 좋은 글

• 개발자 커리어 체크리스트 →
• 개발 커리어 결정 가이드 →

※ 본 글은 AI(Claude)의 초안을 기반으로 편집자 검수를 거쳐 발행되었습니다. (한국 AI기본법 대응 고지)