You read them from a config file and fill them into the config by hand while deploying. Never push secrets embedded into code or portions of the config file to your source repo.

You can hardcode the secrets to test stuff, but the first time you push the code to the repo should be the time you change it to reading from config. And add config to gitignore cause even if you don't stage the particular lines with the secrets in them, there will come one time where you'll rush or will have too long of a day when you'll push those secrets by accident. If you've got a public repo, then it's over. On a private repo then you may not notice this or not remember to remove it with a force push.

A point in time when you get tired of juggling config files manually in dev/prod is the point in time you explore the system for secret management and auto build/deployment as clearly your project has become useful/popular enough.

Those are my IMO and what I use as thresholds. Of course, if your environment is more relaxed there's no limit on further improving this practice.

The long standard for lots of software is to have a blank "file.conf.example" file (with only the variable names but blank values) which you commit to git, and have the code look for a file named "file.conf" which you explicitly exclude from git using gitignore. This allows you to have a template config file while still preventing the secrets from being written to git. Then you can have the software provide some sort of alert when it is launched for the first time saying "config file not found, please duplicate file.conf.example, fill in your details, and name it file.conf."

How to handle organizational secrets is definitely your concern, however, you are probably too junior to be making decisions on implementing security best practices in production. Likely your company has methodologies in place to deal with deployment secrets. Ask a senior dev how they handle secret management. In many companies there are key management tools such as Hashicorp Vault or Ansible vault. Basically without knowing your environment its hard to tell you what to do, but there are lots of options out there, and your company may have already implemented some of them.

At the VERY least, extract them to Environment Variables... ensure .env is on your .gitignore, and have your localized/dev configs in your local .env ... production environments should have them set. For more complex environments you can set via a secure key service, or build from there.

Again,. the LEAST you should do is use environment variables and keep the actual keys out of your code. .env files are a developer convenience measure, and easy enough to use side channels. I go a step further and ensure a fallback that might be the dev environment, but that is not the same as any higher environment

We built https://www.envkey.com to solve this problem in a secure and developer-friendly way—perhaps it can help!