Azure DevOps集成Git时SSIS修改合并被覆盖等相关问题咨询

修改被覆盖的核心诱因 #

• SSIS包的.dtsx本质是自动生成的XML格式文件，包含大量无业务意义的自动生成字段（如布局坐标、临时GUID、序列化标识等），Git默认的文本合并策略仅判断行级别是否冲突，只要两行内容不重复就会自动合并，不会校验SSIS的业务逻辑完整性，经常出现文本无冲突但功能代码被覆盖的情况
• Visual Studio默认开启Git自动冲突解决配置，遇到可自动合并的场景会静默执行合并动作，不会像Git Bash一样弹出明确的冲突提示，很多时候覆盖发生了团队成员都感知不到
• 若团队成员提交前未拉取远程分支最新代码，直接执行推送后的合并操作，VS会优先使用本地提交覆盖远程的历史修改，进一步提升覆盖概率

自动生成分支的原因 #

Visual Studio的Git UI插件存在多个自动触发分支创建的逻辑，无需手动执行git branch命令也会生成新分支：

• 本地存在未提交的修改时，执行拉取远程最新代码、切换分支等操作，VS会弹出提示框询问是否创建新分支保存未提交变更，大部分用户未仔细阅读提示直接点击确认就会生成冗余分支
• 误触VS Git工具栏的新建分支快捷按钮、合并冲突时点选"创建新分支解决冲突"选项，都会自动生成分支且不会产生强提示

VS + SSIS组合是否会导致Git行为不可预测 #

Git本身的版本控制逻辑是确定的，不可预测的感知来源于两个适配问题：

• SSIS的文件格式本身就不适配Git的文本合并逻辑，业务逻辑的修改经常分散在XML的不同节点，文本合并的结果无法对应业务逻辑的正确合并
• VS的默认Git配置是为纯代码类开发场景设计的，没有针对SSIS这类自动生成XML文件的场景做适配，默认的自动合并、静默处理逻辑会掩盖大量实际冲突

是否应该切换为TFVC #

不建议切换为TFVC，该版本控制系统已经进入微软的维护生命周期，不会新增任何功能，仅会修复严重安全漏洞，长期使用的维护成本远高于Git。
TFVC的集中式架构也比Git更容易出现修改覆盖问题，仅有的排他签出机制可以降低SSIS开发的冲突概率，但该收益完全可以通过调整Git的配置实现，不需要切换版本控制系统。

微软不推荐TFVC的核心原因 #

• 架构落后：TFVC是集中式版本控制系统，不支持离线提交、本地分支等分布式开发能力，无法适配现在主流的跨区域团队协作、轻量级分支开发流程
• 生态适配差：目前所有主流的DevOps工具链、CI/CD平台都优先对Git做适配，TFVC的周边工具支持已经逐步停止更新
• 研发投入优先级低：微软Azure DevOps的所有版本控制相关的新功能都基于Git开发，TFVC已经没有新的研发资源投入，后续会逐步边缘化

临时解决方案 #

• 统一团队Git配置，关闭VS的自动冲突解决功能，所有合并操作必须人工校验后再提交
• 给.dtsx、.dtproj等SSIS相关文件配置Git二进制合并规则，只要两个分支修改了同一个SSIS文件就直接抛出冲突，禁止自动合并
• 尽量避免多人同时修改同一个SSIS包，若必须并行开发提前拆分包的功能模块，减少冲突概率

内容的提问来源于stack exchange，提问作者Quynh-Mai Chu