Version-controlling SQL Server Databases in GitHub
This article is dedicated to aspects of version-controlling SQL Server databases in GitHub with dbForge Source Control. The described workflow of source-controlling databases applies to all version control systems supported by dbForge Source Control. The choice of GitHub for this article is motivated by the ever-growing popularity of cloud-based version control systems.
Link
The first step we should take after downloading and installing dbForge Source Control is to link a database to a remote GitHub repository. For this, right-click a database in Object Explorer, point to Source Control, and then click Link Database to Source Control.
The Link Database to Source Control wizard opens. To configure a new link to repository, select Manage in the Source Control repository drop-down list.
The Repository Manager window opens. Since we do not have any saved repository settings, we need to click New to configure source control repository properties.
The Source Control Repository Properties window opens. Select Git from the drop-down list. dbForge Source Control allows working with both, classic Git and web-based GitHub. Since we are going to work with GitHub, we need specify URL, login and password to the GitHub remote repository, select the required brunch ans specify Github username and e-mail.
Now we are back at the Link tab of the Link Database to Source Control wizard, where we have the last thing to do, that is to select a Database development model. We will work on the basis of the Dedicated model, where each developer works with his own copy of the database. Finally, we need to click Link to finish the linking procedure.
Initial Commit
The first thing we see after successful database linking is the Source Control Document. Since currently our remote repository is empty, we need to commit our database files to it. For this, we just need to selected all files in the Local Changes section of the document, write a comment, and click the Commit button.
When the commit is over, the document will show that there are no changes in database objects, which means that our local database files and the ones at GitHub are absolutely identical.
Basically, all changes your do with your local copy will be represented on the Local Changes tab. If you do not want to commit certain changes, click the Undo button, and all your local changes will be reverted.
Associating Commits with GitHub Issues
With dbForge Source Control, you can easily associate your commits of local changes with GitHub Issues as well as to close GitHub Issues right from dbForge Source Control.
- To associate a commit with an issue, you need to specify the issue number with the '#' symbol in the Comment text box before committing local changes.
-
To close an issue, you need to add a keyword before the issue number in the Comment text box before committing local changes.
You can use any of the following keywords:
- Close
- Closes
- Closed
- Fix
- Fixes
- Fixed
- Resolve
- Resolves
- Resolved
For instance, we have an open GiHub issue with request to add a test table and close the issue after completion.
After table creation, we need to open the Source Control Document, select the created table in the Local Changes section, and write the following in the Comment text box: Closes #2 (Closes is a keyword to close the issue, #2 is the issue number). After this, we just need to commit the created table.
As a result, we can see that the issue has been successfully closed.
Remote Changes
When other developers modify database files and commit their changes to repository, these changes are represented in the Remote Changes section of the Source Control Document. For instance, a nullable column has been modified to non-nullable. All you need to do for updating your local database is to select changes and click the Get Latest button.
Conflicts
Conflicts happen when you and other developer modify the same database object or its property. For example, you and other developer modified type of the same column. In dbForge Source Control, conflicts are represented in the Conflicts section of the Source Control Document.To resolve a conflict, select it in the Conflicts list and click Get Local to override remote changes with your local ones, or Get Remote, if you want to override your local changes with the remote ones.
The Source Control Document also shows DDL diffs for the conflicts, so you will instantly know what exactly is wrong.
Conclusion
With dbForge Source Control, managing database changes in source control systems is quite simple and straightforward. It will take you just a couple of minutes to link your database to your favorite source control repository, get latest changes from repository, or to update repository with your local changes. Download and try dbForge Source Control on your own. The 30-day trial is right here on the Download page.