我们有两个特性分支，它们都对 SSDT 项目中的数据库模式进行了更改。功能 #2 合并到master功能 #1 之后，并且文件存在冲突refactorlog。
是否可以通过检查更改来确定应该如何手动合并重构日志？鉴于我对重构日志如何工作的理解，似乎在部署到类似生产的环境期间这很可能会失败。
我们如何使用 SSDT 手动合并冲突的架构更改，而不会出现部署失败或数据丢失的可能性？
问问题
157 次
1 回答
1
对于相同的场景，我已经手动修复 .refactorlog 文件中的合并冲突已经有一段时间了。除非我永远留在一个分支中，否则我似乎无法找到一种方法让 git-merge 能够处理更改。该文件只是一个 XML 文件，您会认为它可以处理该类型的文件。
我个人使用带有 Bitbucket Cloud 和 Beyond Compare 的 Sourcetree 作为我的差异工具，因此一旦您开始了解 .refactorlog 文件的布局，修复合并冲突就不会太困难。
我认为这个问题没有答案。我已经承认，如果多个分支的源代码控制是必须的，那么修复这个特定文件的合并冲突是交易的一部分。
对于它的价值，一旦我解决了冲突，我已经在测试和生产中对我的数据库模式进行了很多很多更改，到目前为止没有任何问题。
于 2020-03-06T22:41:50.720 回答