How to use git as source control provider for SQL Server Management Studio

Can we use GIT as the source control for sql managem开发者_如何学Cent studio?

for Database source control within SSMS

Agent SVN - SCC Subversion Plug-in. http://www.zeusedit.com/agent/ssms/ms_ssms.html

or

http://www.red-gate.com/products/sql-development/sql-source-control/

I’ve found out that ApexSQL has a tool that natively supports Git as a source control system. It comes as a SSMS add-in, and offers a wizard you can use to map database objects with the source control systems. To do that:

1. Download and install ApexSQL Source Control
2. Start SSMS and in Object explorer select the database you want to be linked to a source control
3. Right-click the database, and form the context menu, select the Link database to source control option, from the ApexSQL Source Control submenu
4. Select the source control system (in your case it is Git) and choose from 2 database development models - shared or dedicated. Shared model is recommended when you link a database on which multiple developers will work at the same time

   

5. Filter objects which you don’t want to track using source control: by schema, type or name by schema, type or name
6. Provide appropriate login information and repository string. For Git it is: <protocol>://<hostname>:<portnumber>/<Git server name>/<repository> (see example below):

   

More detailed step-by-step instructions can be found in this article: http://knowledgebase.apexsql.com/link-database-source-control-system-2/

Try sql-source-control, a free and open source CLI used to get SQL into source control systems like Git.

https://www.npmjs.com/package/sql-source-control

Microsoft has released SQL Operations Studio. It's a free tool that runs on Windows, macOS, and Linux, for managing SQL Server, Azure SQL Database, and Azure SQL Data Warehouse; wherever they're running. It comes with native GIT support.

You could add Git Bash as an External Tool (Tools | External Tools...):

• Name: &Git (use & to specify a hot key)
• Command: C:\windows\SysWOW64\cmd.exe (32-bit Command shell)
• Arguments: /c ""C:\path\to\Git\bin\sh.exe" --login -i" Finding the path where Git is installed on a Windows system
• Initial directory: $(ItemDir)

Since SSMS is (more or less) a custom version of Visual Studio, you might be able to use a solution intended for VS:

Using Git with Visual Studio

Alternatively, manage your DB source code in Visual Studio from the beginning, not in SSMS. That way (at least in VS2010) you have database projects, integrated deployment and unit testing etc. Or continue using SSMS and check in your code from an external tool when you're ready (not so convenient, of course).

But it depends on exactly what you're doing: SSMS is a DBA tool, VS is a developer tool. Either way, you should be using some form of source control, but it's not clear from the question exactly what sort of files you need to version.

Not yet but if you go to http://redgate.uservoice.com/forums/39019-sql-source-control/suggestions/537681-add-git-support and vote for redgate to add support for git it might get added in the next version. Yes I know it's a commercial product but some products are just good enough to pay for!

Red Gate SQL Source Control has been updated to include Git and Mercurial support (as well as Perforce and TFS). Be forewarned that their DVCS integration is not 100% feature complete in relation to their SVN product, as basic features such as viewing history of an object are not supported from within SSMS. This may be a deal-breaker if other Red Gate tools like SQL Compare are part of your workflow.

Our workaround was to install TortoiseGit or GitExtensions and navigate to the repository on disk to drill into the specifics. It works but is a bit clunky.

VersionSQL is an SSMS source control add-in I've designed to be lightweight and easy to use. In the Object Explorer panel, just right-click on a database or object and click Commit. VersionSQL will script it out to Git/SVN in a neatly organized folder structure.

Check it out at https://www.versionsql.com

There have been a number of answers around this question which you might want to look at but in a nutshell ....

The nature of version control is to store the original file and then the deltas, the difference between the original file committed and and subsequent changes (ok i have made that a bit simpler than it is perhaps) and then to manage the version number and give tools to extract any particular revision you need. This also then allows you to compare previous revisions and roll back (etc. etc.)

The RDBMS is made up of the schema and the and data these change and can change frequently in the case of the data so even if you did VCS what would you compare to do a restore and how would that help? Assuming you have a live system then reverting to an earlier revision would lose all the data stored in the interim and although i have never tried it i suspect could destroy the general integrity of the RDBMS.

The better solution is to use a backup application built for that RDBMS, MySQLdump say in the case of MySQL which makes a snapshot of the data and the structure of the data and store that in a safe place.

Dumps can be scheduled regularly and you can do things like master/slave databases (or other strategies) so you can backup live production databases on the fly without impacting on performance