Azure DevOps中如何在长期分支间保持一致的合并策略？

核心问题在于：feature分支以squash合并到develop时，Git会将feature的所有提交压缩成一个新提交，丢弃原feature分支的提交历史。后续从main/staging以非squash方式合并回develop时，Git无法识别这些变更已经被合并过，会重复引入代码，导致冲突或逻辑错误。以下是几种实用的解决方法：

方法1：统一合并策略，避免混合模式 #

• 改为全非squash合并：feature分支到develop的PR使用普通合并或rebase合并（保留完整提交历史）。这样后续从main/staging反向合并时，Git能通过提交哈希识别已合并的变更，不会重复引入内容。缺点是develop分支的提交历史会更零散，可每季度对develop的历史进行一次整理（比如合并无关的小提交）。
• 改为全squash合并：所有PR（包括main到staging、staging到develop）都用squash合并。同步变更日志时，不在develop上执行合并操作，而是直接在develop分支创建新提交，复制main分支的变更日志内容后提交PR。

方法2：调整变更日志同步流程 #

放弃通过main→staging→develop的合并链同步变更日志，改为：

• 在发布分支生成变更日志后，同时向main和develop分支提交变更日志的单独PR。
• 两个PR分别以各自分支对应的合并策略（main用非squash，develop用squash）合并，确保两边的变更日志更新是独立的提交，避免合并策略冲突。

方法3：使用Git合并策略强制解决冲突 #

如果必须保留现有流程，在从staging合并到develop时，使用ours合并策略：

# 切换到develop分支
git checkout develop
# 合并staging分支，强制保留develop的现有内容（仅保留staging的变更日志）
git merge -X ours staging

这个命令会自动解决大部分代码冲突（因为feature已经通过squash合并到develop），只需要手动处理变更日志文件的合并。完成后推送至远程，即可完成同步。

方法4：引入专门的同步分支 #

• 创建sync-changelog分支，从main分支拉取最新代码，仅保留变更日志的修改。
• 将sync-changelog分支以squash方式合并到develop分支（和feature分支的合并策略一致）。
• 每次需要同步变更日志时重复此流程，保持develop分支的合并策略统一，避免历史不匹配问题。

内容的提问来源于stack exchange，提问作者Charles