Git, Linked Tables, and Branching/Merging
JackAce
Posts: 75 New member
We've migrated most of our SVN repos to Git and developers are working mostly with feature branches that get merged into a develop branch (using the GitFlow branch development structure).
http://nvie.com/posts/a-successful-git-branching-model/
We have several linked/lookup tables that we version control using SQL Source Control.
When merging our updates to these records we often hit merge conflicts since SQL Source Control always puts updated/inserted rows on top and then puts them back in their proper order on the next commit.
This will not work well with developers who most often work out of a feature branch and then merge changes back into a common branch.
Is Red Gate addressing this issue? Is there a current work-around for this? It seems like if we *always* forced the records to be in numeric order then a lot of this headache would be avoided.
http://nvie.com/posts/a-successful-git-branching-model/
We have several linked/lookup tables that we version control using SQL Source Control.
When merging our updates to these records we often hit merge conflicts since SQL Source Control always puts updated/inserted rows on top and then puts them back in their proper order on the next commit.
This will not work well with developers who most often work out of a feature branch and then merge changes back into a common branch.
Is Red Gate addressing this issue? Is there a current work-around for this? It seems like if we *always* forced the records to be in numeric order then a lot of this headache would be avoided.
Comments
http://redgate.uservoice.com/forums/390 ... r-to-merge
This site will make it easier to interact with the people who actually have an influence over SQL Source Control.
I believe there is also a workaround posted that involves using SQL Data Compare to regenerate the SQL data scripts, which it seems to do in a consistent order unlike Source Control.
Hope this helps.