There are two ways to switch branches:

• drop and recreate your database in the destination branch
  This is the simplest method. The only disadvantage is that you'll lose transactional data. If you need this data for testing, you'll have to repopulate your databases.
• resync your schema to match the destination branch
  Use this method if you need to preserve the contents of your database, and if there are only small differences between the branches.

Drop and recreate your database

The simplest way to switch branches is to drop and recreate your database. This resets your environment so you can deploy from the new branch. To do this:

1. In Visual Studio, close your solution.

2. Take a backup of the database contained in your solution.
3. From your local SQL Server instance, drop the database.
4. In version control, select the branch you want to switch to.
5. In Visual Studio, open the solution.
6. To deploy the database, click Start.

Revert pending changes to re-sync your schema

If you need to preserve the contents of your database, and there are only small difference between branches, resync the schema to match the destination branch before you deploy:

1. In version control, select the branch you want to switch to.
2. In Visual Studio, open the solution.
3. Click View > SQL Change Automation
4. Within the SQL Change Automation tool-window, click Refresh.
   The differences between the two branches are displayed.
5. Select the objects in the list, then right-click on them and click Revert selected object(s).  
   The pending object list refreshes and shows objects as identical.
6. To deploy the databases, click Start. 

If there are multiple databases in your solution, you'll need to repeat steps 4 and 5 for each database. To switch between SQL Change Automation projects, use the drop-down list in the SQL Change Automation tool-window.

What differences may cause the resync to fail?

Resyncing your schema will work as long as there aren't substantial differences between the two branches. For example, if branch A contains a migration that dropped a not-null column, clicking Revert selected object(s) on branch B may fail. SQL Server can't recreate the column containing the data.

To prevent this problem in future, you could start taking regular backups of your databases. Then you can restore your development environment to a previous known state before deploying your solution.