
gobinignore
Put an in-place .gitignore into each main package so the loose executable a
careless go build leaves behind stays out of git.
CHINESE README
中文说明
AI Agents
This repo helps keep build output out of git. Within a Go repo, each main
package (has package main + func main) should hold its own .gitignore with
one anchored line /<name> — the executable go build drops there. To scan /
write: run gobinignore -path <repo> (report), then gobinignore -path <repo> -edit (write). Do not pile path-scoped one-offs into a parent/root .gitignore.
Main Features
🎯 Precise, in-place: each main package gets its own .gitignore with an anchored /name line — no globs, no cross-path surprises.
⚡ Two modes: report on its own (a CI gate); -edit writes the missing files.
🧠 Exact detection: parses package main + func main via go/ast, not a naive grep.
🧩 One repo, three faces: import the Go package, run the CLI, let Claude use the plugin.
Installation
# CLI
go install github.com/yylego/gobinignore/cmd/gobinignore@latest
# Go package
go get github.com/yylego/gobinignore
The problem
The standard Go .gitignore catches just the suffixed executables (*.exe,
*.so, *.dylib, *.test). But when you run go build inside a main
package, the executable it drops takes the package name and has no suffix — so
the standard template misses it. It lands in git status, and one careless
git add bakes it into the git log (a bloated repo, a dreaded cleanup, the
works).
The rule
Where an artifact is produced, ignore it right there. Each main package
(has package main + func main) gets a .gitignore inside itself, with a
single anchored line: / + the executable name (a leading slash pins it to
that package; a bare name is a glob that also snags same-named nested paths). Do
not pile path-scoped one-offs into a parent/root .gitignore — that pollutes
the shared rule, needs upkeep as directories come and go, and rots the moment
someone renames that path but misses the second one. A single in-place line is
the one source of truth: it lives beside the code, moves with it, renames with
it.
Usage
# report, no changes (default; exits non-zero if a fix is needed)
gobinignore -path <repo>
# write the missing in-place .gitignore files
gobinignore -path <repo> -edit
How it decides what to touch
It computes each in-place executable path, then asks git check-ignore if that
path is ignored:
- ignored via its own in-place
.gitignore → compliant, left as is.
- ignored via a parent/root path-scoped rule (e.g.
/cmd/app/app) → the
pile-up anti-pattern; -edit adds the in-place one and asks you to remove the
parent line.
- ignored via a rule that hides the entire tree (e.g.
bin/) → covered,
left as is.
- not caught anywhere → needs an in-place
.gitignore; -edit adds it.
It skips generated/vendored trees such as .git and node_modules.
As a Claude Code plugin
This repo doubles as a plugin marketplace, so Claude Code can run the scan and
add the missing ignores on demand:
/plugin marketplace add yylego/gobinignore
/plugin install gobinignore@gobinignore
The bundled plugin knows the rule and runs the CLI at the right moments.
Use as a Go package
Import the package to scan / write in code:
import "github.com/yylego/gobinignore"
res, err := gobinignore.Scan(".")
// handle err, then:
for _, f := range res.Findings {
if f.NeedsFix() {
gobinignore.Edit(f) // writes the anchored /name line
}
}
📄 License
MIT License - see LICENSE.
Contributions are welcome! Report bugs, suggest features, and contribute code:
- 🐛 Mistake reports? Open an issue on GitHub with reproduction steps
- 💡 Fresh ideas? Create an issue to discuss
- 📖 Documentation confusing? Report it so we can improve
- 🚀 Need new features? Share the use cases to help us understand requirements
- ⚡ Performance issue? Help us optimize through reporting slow operations
- 🔧 Configuration problem? Ask questions about complex setups
- 📢 Follow project progress? Watch the repo to get new releases and features
- 🌟 Success stories? Share how this package improved the workflow
- 💬 Feedback? We welcome suggestions and comments
🔧 Development
New code contributions, follow this process:
- Fork: Fork the repo on GitHub (using the webpage UI).
- Clone: Clone the forked project (
git clone https://github.com/yourname/repo-name.git).
- Navigate: Navigate to the cloned project (
cd repo-name)
- Branch: Create a feature branch (
git checkout -b feature/xxx).
- Code: Implement the changes with comprehensive tests
- Testing: (Golang project) Ensure tests pass (
go test ./...) and follow Go code style conventions
- Documentation: Update documentation to support client-facing changes
- Stage: Stage changes (
git add .)
- Commit: Commit changes (
git commit -m "Add feature xxx") ensuring backward compatible code
- Push: Push to the branch (
git push origin feature/xxx).
- PR: Open a merge request on GitHub (on the GitHub webpage) with detailed description.
Please ensure tests pass and include relevant documentation updates.
🌟 Support
Welcome to contribute to this project via submitting merge requests and reporting issues.
Project Support:
- ⭐ Give GitHub stars if this project helps you
- 🤝 Share with teammates and (golang) programming friends
- 📝 Write tech blogs about development tools and workflows - we provide content writing support
- 🌟 Join the ecosystem - committed to supporting open source and the (golang) development scene
Have Fun Coding with this package! 🎉🎉🎉
GitHub Stars
