SQL Source Control lets you version-control the schemas of your SQL Server databases. 

Why should I version-control my database schemas?

Version-controlling is a good idea for a number of reasons:

• You can keep track of changes to your database schemas.
  • Find out when they happened
  • Find out who made them
  • Find out why (using a commit message)
• You can share database schema changes.
  • Share them between team members on different computers
  • Share them to an automated release system
• You can work simultaneously on the same database, without worrying about overwriting other people's changes.

How does SQL Source Control do it?

Normally, it's hard to version-control database schemas because they're not text files. Version-controlling only really works well for text files, because it's easy to tell what's changed in a text file. It's much harder to tell what's changed between two versions of other files, eg binary files.

Databases are just large binary files, so if you tried to version-control one, your version control system wouldn't be able to tell what's happened when you make changes. This means you don't get most of the benefits of version controlling.

SQL Source Control lets you version-control the schemas of your SQL Server databases. 

It generates a version of your database schemas as text files, and links these files to your version control system. This means that, when you make a schema change and commit it to version control, it's easy to see what the change was. SQL Source Control figures out how to turn that change into text files, including any dependencies. 

How does SQL Source Control work?

For more detailed technical explanation, see How SQL Source Control works behind the scenes.