I had trouble figuring out how they got from point A to point B. My best guess is that a file containing database configuration settings had been committed to the Git repo at some point.
Lessons:
- Don't commit secrets to your Git repo. Store them in config files which are listed in .gitignore. Yes, this means you have to manually copy or write config files when you set up different servers, but those servers are likely to have different database credentials and the like anyway, right? If you've found that you've committed secrets by accident but haven't pushed anywhere yet, revert your branch to before the commit and redo or cherry-pick any subsequent commits safely. If it is too late, change the credentials to access the database or whatever other secrets you've revealed.
- Don't put web-accessible files in the root level of a Git repository. Instead, have a subdirectory contain the web-accessible files, and configure your web server to serve from that. That ensures that the .git directory won't be right next to web-accessible files, and has other benefits as well - you can also easily have subdirectories for docs, CLI scripts, and other things that shouldn't be web-accessible right there in the same repo. But if that isn't an option (or even if it is), configure your web daemon to not serve files from .git, or probably any other file or directory that starts with a dot.
- Edit to add one more: As much as possible, lock down access to your database server. An attacker having your database credentials is bad, but they still won't get far if the database server is configured to only listen to connections from the IP address that the web application server is hosted at, or, if they're on the same server, only over local sockets.
Of course, the same applies to other VCSes besides Git.