It’s all a matter of risk. My main argument against is that if you ever want to share that repository with someone who shouldn’t have the password, it’s really hard to remove the password from the git history. You need to rewrite all history to that point. So you’d have to rewrite all the commits, or squash to lose the history that contained the password. And you probably won’t remember to do that, so it’s safest just to leave them out.
Avoid Committing Secrets
To avoid storing secrets in git, I usually add the secret file to .gitignore. Since someone might need to know what was in the now-missing file, leave something like a
gradle.properties.example file, with the redacted fields as "CHANGEME" or something like that, so anyone using the file will know how to create
If possible, substitute from environment variables, so that you won't need to use a .example file. I personally recommend a tool like direnv which allows you to create a git ignored .envrc file, which can be used to set environment variables on a per-project basis. It automatically loads the environment variables from the terminal when you enter the directory. This doesn't always work well with graphical tools though, since their environment variables will be taken from the environment they were launched from.
Some graphical IDEs do support a concept like "targets" or "workspaces", which understands that some configuration options are configured in files that are checked in to source control, and others are specific to the files on your computer.
What's the risk?
If someone got ahold of your signing key, and the password, they could sign a malicious copy of your application.
If they managed to submit this copy to the app store, your users may automatically receive the malicious copy, without any notice that it was changed. Their device would trust it, because it was signed by your key.
Even without an app store submission, they could possibly sign a copy of the application and side-load it onto a device where the app was already installed, which would still trust it because it was signed by the same key.