Don't .gitignore database.yml

Generally, you put into .gitignore stuff that has the following characteristics:

1. Transient artifacts of the development/testing cycle that have no enduring or shared value (e.g., log/*.log, db/*.sqlite3, tmp/*).
2. Artifacts that are purely derivative (e.g., doc/api--I don't know that these are purely derivative; I assume that the contents of this folder are generated by some rake doc fu and that is why this and some other doc subfolders are typically .gitignore'd).

For the above, you really have to contort yourself to find a good reason to put these things into shared source control. And there are clear and obvious downsides to putting them into source control. At best, it's merely confusing and generates needless churn in your repository.

So I was confused when I heard someone casually defend the inclusion of database.yml in the set of things generally included in .gitignore.

Here are the reasons I've heard for keeping it out of the repository:

Individual Preference

Each developer might have their own conventions, preferences for the database (e.g., you like MySQL, I like PostgreSQL; we can just get along).

My perspective is that for any relatively small team-based development, we should pick a tool and use it. Why ever spend anytime on database differences that add no value to what we're trying to accomplish? Does the opposite apply for larger team development? I doubt it. I just don't have a whole lot of useful experience with that type of development. It'd be interesting to hear people with that perspective speak to this. Have you gotten value out of promoting, fostering the "everyone roll your own database.yml" dance?

It's the same thing with editors. Yeah, it seems democratic in a good way to promote pick-your-own-editor. On the other hand, imagine a team that all learns a tool really well. They can share that knowledge with each other. And there's synergy that comes from that.

Security of local development database concerns

The preferences might extend to a continuum of security-centric preferences (e.g., you think username=postgres is the way to go with local trust; I think I need to have a super cryptic password so no one can hack my local database).

I tend to think that setting up your database server so that it only listens locally is generally good enough for me. Do you work with people who think otherwise? Are their concerns legitimate? I'd love to hear real experience related to this.

Security of production credentials concerns

You might have production credentials in database.yml, so adding it to .gitignore keeps those credentials safe.

Um, seriously? Your production credentials are sacrosanct and yet sitting in developer's working directories? It's hard to take this seriously. It's trying to play both sides.

Summary

This is why I recommend people reconsider adding database.yml to .gitignore.

The practice adds no obvious value. It confuses the point of .gitignore and promotes a do-it-your-own-way type of thinking that counteracts the virtue of leveraging conventions in the context of team-based development.