We have struggled with this for a few years now.
We tested out RedGate Source Control with SVN (Subversion) on a few projects and found that we had a few issues with it. We spent more time fixing problems with conflicts and the way in which RedGate works that we soon abandoned it and adopted our own approach (marginally based on what RedGate actually does)
The way redgate tracks changes is through extended properties against each object we do the same now (where every objects has a version number and release date in an extended property attached to it) we use SSDT with VS (as our devs use that anyway) and we store the DB build as part of the software repository so it is branched and merged as part of the same base.
You need to take not that DAC or BAC dont support extended properties, so if you are deploying to Azure it can be a bit problematic how ever fresh deploys are reasonably straight forward from SSDT itself.
SQL Server seem to have started down the route of using DAC to deploy and upgrade databases, however thus far have not included data. You can create and deploy a BAC file with the data, however the features to upgrade aren't as mature as just DAC.
The biggest problem we find is DATA itself, especially when deploying to a live system where customer data also muddies the outcome a little.
In some cases where tables have had to be restructured etc etc it can be a rather messy conversion script.