The password has to be recoverable somehow with data available to the script at run-time. So you could certainly include some kind of obfuscation scheme that made the password less obvious in the script, but in the end it doesn't get you anything—as long as the information is readable by the script, it'll be readable to an attacker who has obtained the script.
The usual answer is to put the password outside the script, in a separate file that can be read by the script code. Indeed, it is a good idea to split all the deployment-specific details such as database connection string into a separate file (typically a config file or invocation stub), so you can manage the code logic separately from the deployment details.
In a server-app scenario you can then lock down the permissions on the config file so only admins and the service user can read it; in a client-app scenario you can require each user to get their own database credentials. Either way, since the script itself now contains only the logic it is safe to distribute it and manage it using a source code repository.