Version control with Git in Azure DevOps

Azure DevOps is a platform that helps development teams build and deploy software products by providing a number of planning, collaboration, management, and automation tools.

The easiest yet most effective way to version-control SQL Server databases in Azure DevOps involves dbForge Source Control, an SSMS add-in that helps you perform the following tasks:

Commit and revert changes
View and resolve conflicts
View the history of changes
Link static data
Update the local version with the latest changes

Create a new project in Azure DevOps

First, you need an Azure DevOps project. If you have to create one from scratch, sign in to your Azure DevOps account. Then click Start free. If you need a project for a new organization, click New organization, specify its name, indicate your country/region and the preferred hosting location, and, finally, start creating a new project with the following steps:

Specify a name for your project and set the visibility depending on whether you want your project to be private or public
Optionally, enter a project description
Select Git from the Version control drop-down list
Select a Work item process according to your needs (the available options include Basic, Agile, CMMI, and Scrum)
Once it's all done, click Create

After that, a new project with the repository is displayed on the Projects page where you can commit, push changes, add files, and make changes. If your project is private, make sure your have provided the required users with the access to your repository.

dbForge Source Control - Creating a new Azure DevOps project in the Azure DevOps account

Invoke dbForge Source Control from SSMS

To get started, download and install dbForge Source Control, and then open SQL Server Management Studio. In Object Explorer, right-click the database to be linked to a repository and select Source Control > Link Database to Source Control.

dbForge Source Control - Link a database to Source Control

Link a database to the Azure DevOps project

In the Link Database to Source Control wizard, under Source Control repository, click Manage to open the Source Control Repository Properties dialog. There you will be able to configure the following source control settings:

Select the source control system
Specify the repository folder name
Edit the auto-generated repository name, if necessary

Optionally, you can test the settings you've provided. Click OK to return to the previous window where you can select the database development model and finish linking the database to the Azure DevOps project.

dbForge Source Control - Set up the TFVC source control repository

Make an initial commit

Once the required database has been linked to Git, the Source Control Manager opens displaying all the files that can be committed to the remote repository. Since the repository is empty, you need to make an initial commit. To do so, in the Local Changes section, select all files, write a comment, and click Commit. In the Commit dialog, click OK.

Upon a refresh, you will see that there are no local changes in database objects. Yet when you switch to the remote repository, you will see that it contains all the local database files you have committed.

In case you do not want to commit certain changes, select the said changes and click Undo.

dbForge Source Control - Make an Initial Commit

View database files in Azure DevOps

After the initial commit, you can start working with database files: modify them, commit local changes, update the local copy of the database with the latest changes from the remote repository, revert uncommitted changes, and resolve conflicts, if any.

In your Azure DevOps account, you can view linked database files in Repos > Files. If you want to see the history of changes, switch to the Changesets page.

dbForge Source Control - View database files and changes history in Azure DevOps

Get remote changes

There is a common situation when several developers collaborate on the same database, make changes in its files, and commit them to the remote repository. You need to be able to get these changes and keep your local copy up-to-date.

In order to get the latest changes, proceed to Object Explorer, right-click the database you want to update, and select Get Latest. Alternatively, in the Remote Changes section, select the required changes and click Get Latest.

dbForge Source Control - Get the latest changes from the remote repository

Resolve conflicts

When you make changes to the same database file(s), you may face conflicts that will be displayed in the Conflicts section of the Source Control Document. In this case, conflicts should be resolved either by overwriting your local changes with the remote ones (the Get Remote option) or by accepting the local changes and thus overriding the remote ones (the Get Local option).

At the bottom of the Source Control document, you can see local (left pane) and remote (right pane) DDL differences.

dbForge Source Control - Resolve conflicts

Work with multiple branches

dbForge Source Control allows using multiple branches simultaneously. This drastically simplifies database development and helps fix various issues separately, test them locally, and then merge them into the main branch. Using Source Control, you can easily connect a SQL Server database to a specific repository and switch between branches.

Conclusion

dbForge Source Control offers the quickest and simplest way to version-control SQL Server databases and manage database changes. Its functionality includes linking a database to the remote repository, committing local changes and getting the latest ones from the repository, associating work items with commits, reverting uncommitted changes, viewing the changes history, and resolving possible conflicts. Get a free 30-day trial of the advanced SQL Tools pack—which includes dbForge Source Control—and check all of its rich capabilities in action.