It is standard security practice to try to avoid committing keys, yes. Unless it's to a private repo you know will never be made public.

There are a variety of options, depending on what type of software you're developing, how much you're willing to be locked into third party tools, and things like that.

The simplest is to just save the credentials somewhere like the user's home directory, outside of the git repo. This is what a lot of command line tools do.

Environment variables are also a popular option - most CI build systems will let you store 'secrets' that are passed into the build process as environment variables.

Larger scale projects will often end up with a configuration management mechanism, enabling 'configuration as code'. When doing this it will often be interlinked with credential management. After all, why not store the hostname of the database alongside the username and password?

If you're in a cloud environment, they will have 'instance metadata' that can (with configuration) pass cloud provider credentials into your instance. They will often provide a secret store service you can access using those credentials, and will let you authenticate to databases and blob stores and whatnot using those credentials so long as you stay within their cloud ecosystem.

Large corporations like 'credential rotation' where secrets get revoked and re-issued on a regular basis. The cloud environment can do this between your instance and their provided services - or you can do it yourself in an ad-hoc way.

All the major PC operating systems provide a secret storage function or 'keyring' although it's debatable whether it's all that different to just saving a file on disk. It used to be, back before the rise of full disk encryption though.

And of course if you're writing a mobile app, the operating system is a lot more locked down. So there you can store credentials in the system keyring and other applications can't access them.