.gitlocal：Gitでの機密ファイルのデフォルト無視を提案する新概念

I was building a CLI tool that records sensitive info in a dot folder, and went looking for best practices to avoid those folders being accidentally committed to git. To my surprise, git doesn’t really provide a way for tool builders to declare that their files shouldn’t be committed. That got me thinking: what if there was a file you could drop in your dot folder, or a comment you could add to the top of a file, or a naming convention you could use, that git would ignore by default?

Today, the best a tool author can do is append a line to .gitignore

Git’s existing ignore mechanisms all require someone other than the tool to act. .gitignore

--assume-unchanged

--skip-worktree

.git/info/exclude

.sometool/config.json

.sometool/credentials.json

credentials.json

Tools that write sensitive files usually write them into their own config directory, so the directory marker covers most cases. A tool that writes standalone files and controls the filename could use a .local.json

.sometool/credentials.local.json

.sometool/credentials.json

New tools ship all the time, and their authors currently have to choose between modifying the user’s .gitignore

The idea of a marker file that changes tool behavior isn’t new. Android’s .nomedia

--exclude-if-present

The obvious objection is invisible behavior: a file that suppresses its own tracking could surprise people. I think the scale of the secret-leaking problem has outgrown that concern. GitHub is revoking millions of tokens a year, and that’s just the ones they can detect. The semantics can be tight enough to avoid surprises: .gitlocal

git check-ignore

Getting this into git itself means a patch through the git mailing list and convincing the maintainers it belongs in core, a high bar. In the meantime, I built a proof of concept pre-commit hook that checks for all three conventions: marker files, file extensions, and first-line comments. You lose the experience where git just knows, but tool authors could start using the convention today and build an evidence base for a core proposal. That’s more or less how .gitkeep

Sure, another dotfile in the growing pile. But every leaked secret means rotated credentials and audited access logs, sometimes worse. An empty marker file in a tool’s config directory seems like a reasonable tradeoff, especially for tools being written right now by authors who know exactly which files are sensitive and have no good way to act on that.