Why we don't recommend using Shared Mode with Git

We don't recommend using Shared mode with Git; here's an example of why:

Our database development team is Alix and Bob.

 Alix and Bob develop against a single, shared database. They use SQL Source Control to commit their changes. They use git as their VCS. Like a lot of git users, they have a central repo (stored on github), and local clones of those databases.

 Alix adds NewTable_1 to the development database.

 At this point, both Alix and Bob are in the same state:

• A new table is in their database
• It isn’t in their local git repo (i.e. will be on SOC’s commit tab)
• It isn’t on github

 Since she’s a clever one, Alix immediately commits that change to her local repo.

 Now they diverge:

• A table is in the database for everyone
• It shows as uncommitted for Bob, but committed for Alix. This is different to shared model for SVN, Vault and TFS
• It isn’t on github

 Let’s say that Alix is super-disciplined and she pushes that change to github right away. Where are we now?

•  A table is still in the database for everyone
• It still shows as uncommitted for Bob, but committed for Alix
• The table is on github, but Bob still has no idea about that

 So what does Bob have to do? How does he get back in sync?

 Well, there are options:

1.  He could commit Alix’s NewTable_1 himself. That makes things look the same on the commit tab in SOC. But that actually means that he and Alix have different git commits with the same content. That’s an easy way to get merge conflicts*, and could prevent him pushing his changes to github
2. He arguably should pull Alix’s changes from github to get his local git repo in-sync**

Pulling is an action you do on the ‘Get Latest’ tab, which is considered all-but-redundant when using the Shared model. Once you need to perform that pull step, the behavior of Shared and dedicated model are really very similar.

 So that’s the important difference:

• Distributed git repositories mean that, even if the database is centralized and shared, users will often need to coordinate their repositories by both pushing and pulling (steps not used in any other VCS that SOC supports)
• Attempting to manually synchronize local repositories by duplicating commits can easily lead to merge conflicts
• For people to synchronize local repos without leaving Management Studio (or SOC, at least), they need to use the Get Latest tab

 * for clarity, this simple example may not actually result in a merge conflict, but it’s an intentionally trivial example.

** when he pulls, his git repo will get Alix’s committed copy of NewTable_1. SOC will see that’s the same as the database version, NoOp it and everything will be right with the world.

However if you particularly want to use shared mode, you can link using the Custom Setup.

Please note that if you use the Custom Setup you will not be able to Push/Pull from the remote repo or view revision history in SSMS. 

In this scenario you should ignore the statement "There are no changes to get" on the "Get latest" tab and regularly fetch or pull changes from Git using an external Git client.