`git add -p` is your friend to avoid adding unintended files/changes.

I think the article starts out correct, but as soon as it recommends letting through `*.go` it becomes mistaken.

I'd say the correct approach is to include all your top level files (i.e. CMakeLists.txt, .gitignore, etc.) but also your top-level *directories*, i.e. `/renderer`, `/UI`, `/tools`, whatever.

Then, crucially, your build system must also prohibit in-source builds and require a dedicated build directory.

This way, it's presumed that everything in your source tree is pristine and correct, and can host a variety of file types depending on your needs (realistically, source trees can contain lots of things; data, json, images, text, etc.) while you also shouldn't have to worry about polluting it accidentally.

I've done something like this to understand how a unity project would interact with git + LFS as a novice to the ecosystem.

I'd incrementally add files until the project would load successfully after a fresh clone. Handling of subsequent concerns like lightmap data and external services became a lot easier having had the experience built up from zero.

This is a great technique if your workplace is fussy about what's allowed on GitHub. We have used it for many years.

Alternative: create a .ignore folder for stuff that doesn't belong to repo at all, like your personal notes. Of course, .env shouldn't be there, because it's expected by your code, put it in .gitignore as usual. And stuff like .DS_Store should be in your global gitignore via core.excludesfile config.

There, problem solved. This covers all cases I think.

I use this strategy on my home directory for tracking dotfiles.

I use alint [0][1] to define and enforce rules about files/globs that should or shouldn't be committed, among other things. You can configure it run as a pre-commit hook or in CI.

(disclaimer - this is my own tool)

[0] https://github.com/asamarts/alint

[1] https://alint.org/docs/rules/git-hygiene/git_no_denied_paths...

You should have editor specific and platform specific files in your global gitignore.

https://codeberg.org/ziglang/zig/src/branch/master/.gitignor...

That fixes the problem of every project enumerating the settings files for every editor.

Then, as others have said, you should commit only the files you intend to commit; and ignore the files that you don’t intend to commit. This shouldn’t be difficult if you’re reviewing what you’re committing anyways.

Listing new files is easy with git status, at which point you can decide to ignore them. If everything is ignored, how do you know what files are new in order to know to un-ignore them?

This approach is actually ideal for Docker ignore files to reduce bloat of your Docker images.

i am not sure why this has been upvoted this is such a bad advice...