Shared model

A shared development model allows every developer to work on the same database and repository that contains the most recent database version.

Shared Dev Model


Firstly, all developers install dbForge Source Control on their machines so that they can all commit their changes.

Then, any of them needs to link the database to version control and make the initial commit.

It is required to specify the Shared Model mode when you link a database to a repository.


Once the database schema has been committed to version control, all developers can start making changes.

The workflow is as follows:

There’s no need in updating the database with the latest changes from version control, since all the changes are already in the database that are being developed.


The repository contains all changes made. To learn how to view changes history for the entire database or separate database objects, refer to View Source Control history.


If two developers make changes to the same object, only the changes made by the last of them will be saved to the database. There is no way to detect what changes another developer was trying to make to this object. That is why using the dedicated model is a better practice.

Get latest

There is no concept of getting remote changes in the Shared development model since all developers work on the same database and repository. Consequently, all modifications are directly applied to the shared database. Once a change is committed to the repository, it is already in the database that all developers are using. Therefore, there’s no need to fetch remote changes because the most recent version control updates are already available in the shared database environment.


Shared model requires only one development database, i.e. there are fewer instances of SQL Server required.


There is no safe way to test changes in isolation.

Switch to dedicated development

1. Unlink the database from source control.

2. Create an empty database. It will be your dedicated copy.


For easy identification, you should name the database something similar to database you’re about to copy.

3. Link the created database to the source control repository that the shared database is linked to.

4. Get the latest changes to update your dedicated copy with the changes from the original database.

Want to Find out More?



Take a quick tour to learn all about the key benefits delivered by dbForge Source Control for SQL Server.
All Features

All features

Get acquainted with the rich features and capabilities of the Source Control in less than 5 minutes.
Request a demo

Request a demo

If you consider employing the Source Control for your business, request a demo to see it in action.
Ready to start using dbForge Source Control for SQL Server?