我们在项目 XML 文件 （*.sqlproj） 方面一直存在问题。如果添加/翻新/更改了文件的位置，则它会自动在某些意外位置添加/删除记录。在那之后，当有人也更改该文件时，我们通过合并它会遇到很大的麻烦。
我们得出的结论是，我们可能会在入住前对其进行分类。我们将按字母顺序对其进行排序，在这种情况下，合并工具将更好地理解它。
所以，我的问题是：
- 是否可以在每次签入之前以某种方式重新排列sqlproj文件？也许已经有某种选项/工具可以做到这一点？
- 还有其他方法可以让开发人员的生活更轻松吗？
更新：
我再次遇到了同样的问题。 sqlproj 文件被修改了 3 次，我只想合并到生产中，只有最后一次更改，其他 2 个尚未测试。 在合并工具中，我可以选择添加所有这 3 个新对象或保留它而不进行更改。我不能只选择最后的更改...
例：
- 开发者 A 创建了表 A 并签入;
- 开发者 B 获取最新版本的开发分支，创建表 B 并签入;
- developerC 获取了最新版本的开发分支，创建了 tableC 并签入。开发人员 C 测试了代码并准备投入生产。他试图将他的代码合并到 QA 并得到冲突，他只能选择所有更改。
我非常了解您遇到的场景。当您在单个存储库的上下文中发生多个工作流并且您没有通用的升级计划时，通常会发生这种情况（因为所有工作将同时转到 QA 和同时转到 PROD）。
我能想到几种方法来解决这个问题，每种选择都有优点和缺点。
-
锁定每个环境，直到所有环境都可以一起提升。在大多数情况下是不现实的。
准备好升级 时，请从源环境创建升级分支，并从升级分支中删除尚未准备好提升到目标环境的内容。这使开发人员可以继续工作并能够在不冻结的情况下进行推广。
混合方法...在 Dev 准备好提升到测试之前，不要在 Dev 中源代码控制任何内容。然后从那里开始执行选项 #1 或 2。
创建一个更灵活的生态系统，可以为每个功能分支启动一个环境，以便与其他分支一起演示/测试（或至少在开发人员之间分配/轮换足够的环境以实现相同的目标）。一旦被接受，就提升。这就是我们目前正在努力的目标，但是当您拥有大量共享它们的互连数据库和应用程序时，构建基础架构和流程至少可以说有点挑战（尤其是在Microsoft世界中）。
无论如何希望这有帮助...
1 - 您使用什么源代码管理？我知道没有源代码管理了解sqlproj文件的上下文，但这通常不是问题。
2.a - 这不应该是你经常遇到的问题，你定期入住/退房吗？如果不同的开发人员对项目进行大规模更改并且之前和之后没有签出/签入，我只会希望看到问题。
2.b - 也可能您没有正确合并，如果您同时进行两组更改，那么通常没问题。
艾德