There are numerous ways to accomplish this but there is no SQL Server feature solution that I'm aware of. This is both a very common and rather difficult problem.
My preferred (and the most difficult) method - Abstract the persistence away
During development you can call an in-memory persistence service built to help you iterate and to pre-hydrate data for well-known scenarios and to help with tests. In production and during integration testing you hook into the database persistence service. This also helps you when you want to move some or all persistence to a different technology (you need to add search, move to CQRS, etc). A lot of people call this "database as a service" and often use domain rather than CRUD methods
UpsertUser(UserDTO). This takes a lot of work up front though.
Visual studio database projects
You can quickly switch between schemas by publishing you current branch's version of the database project. Since this is a model-first deployment method (as opposed to change-script based) it works great with source control, especially branching, but you may need to publish the schema each time you change branches if you share a database. You also may need to create hydration scripts if you keep dropping and re-adding columns and you may have coordination issues between people sharing the database. This is what I've used most often in practice and I love that after each publish I KNOW my schema is correct and I can go to any commit - publish it - and have that same guarantee.
If you use a SAN or NAS often they support the ability to take a snapshot and write to it. SQL server snapshots are read only so if you still want to write, this is your fastest option. It can instantly give you a new identical db to work from and you can have it be your production db if you'd like (obvious security concerns here!). This is tough to setup and I've never had an automated solution like this but I'm sure it's possible. You can accomplish the same thing with database backup/restore and it'll be easier to automate but if you have a big development db it may slow you down.
You can also use synonyms to accomplish exactly what you're looking to do although it'll be tedious to setup. We use synonyms to create fake replicated databases in staging environments. Anyway, create your real databases like
DB_ABC124 and then create a database
DB with synonyms that point to the objects in your desired database. You'll have to run a script each time you change branches to swap the synonyms (you may be able to automate this with GIT, I'm not sure) but this should allow you to switch between DBs without changing configs. Honestly I'd rather just have different configs tracked in my branches though.