No, or not really.

Here's how the items should work. When I implement VCS, I check in my entire C# project or script out and check in my entire database schema. We're in sync.

The DB exists on a server instance. It's there, and it's a central point of access for everyone. I make a change to a schema object in SSMS. That change only exists in my editor.

Once I execute the change, I've then changed the server. If this is my own server, I only affect my own work. If it's a shared server, I potentially impact other developers and slow them/interrupt them.

In both cases, I should have a script file (even using the GUI, save the script file) that I can save and commit to VCS. This is either a new commit or an update to an existing object. This happens the same as a C# commit from VS. The RG tooling (or VS tooling) makes this easier from one front end as opposed to the VCS client, but in either case, I manually commit.

At this point VCS looks like the database (or the C#project). We're now in sync.

The idea is I repeat this over and over, making changes that cause my project or database to become out of sync with VCS and then I sync it back up. Tooling makes this easier, but it needs to be done.

There's no need to script my project or db objects constantly and determine what's changed. I check in things when I change them and the compile/testing says they're good enough to check in.

Auditing is a process that periodically (probably daily) looks at VCS and my project/database and determines what's out of sync. If something is, I send a note to the mgr/developer to check things in.

Tooling is there to make it easy for a developer to see what he/she has changed, or what others have changed by looking at VCS -> project/db comparisons and determining differences.

If you work with a dedicated db for each developer, the RG tools will easily pull the entire project from VCS and drop it onto an instance/db for the developer.