.gitignore 기본값을 '모두 무시'로 바꾸면?
.gitignore Everything by Default

실수로 .DS_Store, node_modules, IDE 설정 파일, 심지어 환경 변수까지 커밋한 경험이 누구에게나 있다. 이 글은 기본적으로 모든 파일을 무시하고, 필요한 파일만 명시적으로 허용하는 역발상 .gitignore 전략을 소개한다. Go 프로젝트를 예로 들어 '*.go', 'go.mod', 'go.sum' 등만 추적되도록 설정하는 방법을 보여주며, typescript-go의 207줄짜리 .gitignore를 언급하며 과도한 무시 규칙의 대안으로 제시한다. 또한 git에서 특정 파일이 무시되는지 확인하는 명령어와 lazygit 같은 유용한 도구도 팁으로 소개한다.
What if we flipped this approach entirely? Instead of allowing everything by default and selectively ignoring files, what if we ignored everything by default and only allowed specific files?
HN 토론
156- rcfox
좋지 않은 조언인 것 같습니다. 저는 실수로 커밋해야 할 파일을 추가한 경우는 거의 없었지만, 커밋하려는 파일을 무시 목록에서 해제하는 것을 100% 잊어버릴 것입니다.
모든 것을 gitignore하는 초기 설정 단계를 한다면, 왜 일반적인 파일들을 gitignore하는 초기 설정 단계를 하지 않습니까? 모든 저장소에 복사할 수 있는 템플릿을 만드세요.
- Brajeshwar
꽤 많은 개발자들이 혼자 일하거나, 충분히 많은 사람들과 일해본 적이 없거나, 충분히 많은 프로젝트를 경험해보지 못한 세계에서 나온 것 같은 조언을 하는 것이 이상합니다.
이 경우, `.gitignore_global`이 그가 언급한 일반적인 파일들(`.DS_Store 파일, IDE 설정, 압축 파일 등`)을 처리해 줍니다. 심지어 문제가 발생하더라도, 일반적으로 중요한 파일이 들어가기 전 초기 스캐폴딩 단계에서 발견됩니다.
신입 개발자나 주니어 개발자와 함께 일한다면, 글로벌 gitignore, 로컬 설정, dotfiles 등에 대한 전형적인 교훈을 주고, 영감을 주거나 시작점이 될 만한 자신의 설정을 공유하세요.
편집: 제 dotfiles가 인터넷에서 최고는 아니라는 것을 알고 있지만, 여러 기기, 여러 정체성(회사, 프로젝트, 개인 등)을 쉽게 전환하는 데 도움이 되었습니다. 최근에 정리하고 Claude Code로 자동화, 테스트 등을 추가했습니다. https://github.com/brajeshwar/dot
- isityettime
`git add`를 올바르게 사용하는 법을 배우는 게 어떨까요? 항상 `git add -A`를 막 치는 것에 그렇게 집착하시나요? .gitignore를 전혀 건드리지 않고도 작업 트리에 커밋되지 않은 파일을 두는 것은 어렵지 않습니다.
- caseyw
저는 기본적으로 무시하지 않고, 명시적으로 원하는 항목만 스테이징합니다.
페어 프로그래밍을 할 때 상대방이 그냥 "git add ."라고 말하는 것을 얼마나 많이 봤는지 모릅니다. 저는 항상 그 선택이 혼란스럽습니다.
이해는 하지만, 모든 것을 추가하는 것보다 일관되게 선택적으로 추가하는 것이 더 많은 문제를 일으키는 것을 봤습니다. 각자 취향이죠.
- flexagoon
> CLAUDE.md 같은 기타 정크는 저장소에 있으면 안 됩니다.
CLAUDE.md/AGENTS.md가 "저장소에 있으면 안 되는 정크"라는 게 어떻게 말이 되나요? 프로젝트에 에이전트를 사용하고 프로젝트별 규칙이 있다면, 저장소에서 에이전트를 사용하는 다른 사람들이 그 규칙에 접근하지 못하고 더 나쁜 코드를 만들게 하려는 이유가 무엇인가요?
- yipinwong
보안 엔지니어적인 접근 방식이네요.
VPS에서 모든 포트를 차단한 다음 하나씩 열어보는 것과 같습니다.
여기서도 파일에 같은 접근 방식을 사용하는 것이죠.
유일한 단점은 어떤 파일을 허용할지 알아야 한다는 것입니다. 포트의 경우 쉽지만, 파일은 다양한 확장자를 가질 수 있습니다.
앱/CLI 등은 이전에 본 적 없는 확장자의 파일을 생성할 수 있어 문제가 발생할 수 있습니다.
그 외에는 이 접근 방식이 마음에 듭니다.
- matthewmc3
모든 것을 무시하는 것에 대해서는 확신이 없지만, 제 git 워크플로우에 했던 최고의 변경 중 하나는 ~/.config/git/ignore에 `.*`를 추가하여 기본적으로 모든 dotfile을 무시하는 것이었습니다.
이제 프로젝트에는 일반적인 파일들을 무시 해제하는 보일러플레이트(!.gitignore, !.gitattributes, !.github, !.editorconfig 등)가 필요하지만, 그 후에는 .foo.lang 파일이나 .tmp/.cache 디렉토리, .code_analysis.md나 .todos.txt 같은 Claude 헬퍼 등을 프로젝트에 던져 넣을 때 .gitignore를 관리하는 것을 잊어버리는 후폭풍을 처리하지 않아도 됩니다. 더 많은 사람들이 이 방법을 사용하지 않는 것이 놀랍습니다.
- ryanbrunner
이 접근 방식의 문제점(그들의 첫 번째 예에서 이미 드러나지만)은 거의 즉시 "이 유형의 파일은 괜찮다"는 식의 해결책으로 시작하게 되고, git에 무엇을 넣어야 하는지는 파일 유형과 그렇게 강한 상관관계가 없다는 것입니다.
또한 `git status`를 불구로 만들고, 무시된 파일은 거기에 표시되지 않으므로 본인이 변경한 내용을 스스로 추적해야 하며, `git add .`가 안전하다는 잘못된 안도감을 심어줄 수 있습니다.