SourceControl + GIT + Shared Model

AlexTs

Hi We have a project where works team of 15 developers. 
We are looking for solution for using SourceControl for SQL server.
I have tried the redgate source control, and see that the Shared model is not support with GIT repository.
So first question is what is the reason? Maybe this will be changed later?
Second question is there a way to somehow workaround that?
Maybe use local folder and link it to git?
Working with the dedicated model is not an option, since I can't see who made a change.
In worst case scenario will try svn or tfs. 

DanC

Hi @AlexTs

There are no plans for Git to be supported in a shared environment, and this is the rationale:

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.

1. 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 behaviour 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 centralised 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 synchronise local repositories by duplicating commits can easily lead to merge conflicts
• For people to synchronise 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.

If after reading the above you still want to use the shared mode, there is a workaround you can use, which is to set git using a custom configuration file.

AlexTs

Hi DanC,
Thanks for explanation