Migrate databases using Git and dbForge Source Control

Last modified: March 28, 2025

When you manage SQL Server databases across different environments using Git, dbForge Source Control can ensure smooth change management and better collaboration among team members.

This guide demonstrates how to set up and handle a database version control workflow, assuming you have two environments — Development and Production — and a Git repository, which contains the latest version of your database schema.

Step 1: Set up version control for development

First, you must integrate your development database with the Git repository. In this step, you do the following:

1. Clone the repository.

Here you need to clone your Git repository, which contains the database schema, to your local machine. It is the main repository that will keep track of all changes and updates.

2. Link the Development database to the repository.

To learn how to link the databases to a Git repository, use the instructions from the Link a database to Git documentation topic.

3. Make an initial commit.

After linking the database to the repository, dbForge Source Control will display the differences between the database and the repository. Commit the required changes from the database to the Git repository to ensure both are in sync.

For more information about how to commit changes in dbForge Source Control, see Commit changes.

Step 2: Develop and commit changes

When you work in the Development environment, you do the following:

1. Create a Git branch:

Create a new branch for your task, for example, feature/add-new-table, to isolate changes from the main branch.
Use this branch to make and test changes in the Development database.

2. Make changes:

Modify the database schema or data as required.

3. Review and commit changes:

Use dbForge Source Control to view pending changes.
Commit the changes to your local branch in Git.

For more information about how to work with multiple branches, see the Working with Multiple Branches in Source Control blog article.

Step 3: Collaborate and review using pull requests

Before deploying changes to the Production repository, you must do the following:

1. Update your branch:

Fetch and merge the latest changes from the main branch to ensure your branch is up-to-date.

2. Open a pull request:

Create a pull request to merge your feature branch into the main branch.
Add a description of the changes for review.

3. Conduct code reviews:

Team members review the pull request, discuss the changes to ensure they meet requirements, and resolve any conflicts.
If everything works as expected and possible conflicts are resolved, the pull request gets approval, and you can merge it into the main branch.

Note

The workflow for handling pull requests may vary depending on the Git platform you are using. For more information, refer to the documentation specific to your platform.

Step 4: Deploy to Production using source control

After the changes are merged into the main branch, you should:

1. Link the Production database:

In dbForge Source Control, link the Production database to the same Git repository as the Development database. For more information about how to link the databases to a Git repository, use the instructions from the Link a database to Git documentation topic.

2. Deploy to Production:

Use dbForge Source Control to deploy changes from the repository to the Production database. For more information, see Deploy from Source Control.

Note

Changes are applied immediately and cannot be undone, so make sure to back up your production environment beforehand.

In addition, dbForge Source Control can version-control database schemas and static data.

Automate database deployments

You can also automate database deployments using automation tools or scripts when changes are merged into their corresponding branches. This operation can ensure that your environments are always up-to-date with the latest approved changes.

Suppose you have a source scripts folder that you want to deploy to a target Git repository.

The workflow would be as follows:

1. Create a scripts folder from the database whose schema changes you want to deploy.

2. Link that source scripts folder to a target Git repository.

3. Create a .bat file with the PowerShell script that runs the schema comparison between a database and a scripts folder and detects any changes.

4. If the script does not detect any changes, no further action is required. However, if any schema changes have been identified, the scripts folder will be synchronized with the repository, and the changes will be automatically committed and pushed to the Git repository.

Here is a blog article with a step-by-step guide and examples to deploy schema changes: How to Automatically Commit SQL Server Database Schema Changes to the GIT Repository.

To learn how to deploy changes using the dbForge tools, you can also see the following documentation topics:

By following these steps and utilizing dbForge Source Control, you can easily manage SQL Server database changes between different environments using Git pull requests, thus improving the collaborative development process.

Was this page helpful?