GitFlow完成热修复时将master非预期内容合并至develop分支

嘿，这个问题我之前帮好几个团队解决过——GitFlow的默认合并逻辑确实会在热修复完成后把Master里的配置（比如你说的NuGet依赖版本）带到develop里，尤其是当两个分支的环境配置本来就该不一样的时候，这简直是个烦人的意外。下面是几个实用的解决办法，你可以挑适合你们团队的：

方案1：为环境特定配置文件设置「保留当前分支」的合并策略 #

这是最省心的长期方案，核心是让Git自动忽略特定配置文件的跨分支合并变更：

• 首先把NuGet依赖版本这类分支专属的配置，单独抽离到一个独立文件里，比如Dependencies.props或者NuGet.Env.Config，不要和其他代码混在一起
• 在仓库根目录创建（或编辑）.gitattributes文件，添加一行规则：

  Dependencies.props merge=ours
  

• 执行全局Git配置，让它识别这个合并策略：

  git config --global merge.ours.driver true
  

  这个配置的意思是：当合并时遇到标记为merge=ours的文件，直接保留当前分支（也就是develop）的版本，完全忽略来自Master分支的变更。

方案2：手动处理合并冲突，保留develop的配置 #

如果不想改Git全局配置，也可以在热修复合并时手动干预：

• 当执行git flow hotfix finish <hotfix-name>时，Git会尝试把hotfix合并到develop，这时候如果配置文件出现冲突，不要直接用默认的合并结果
• 打开冲突的配置文件，手动保留develop分支里的NuGet版本内容，删除Master带来的变更标记（就是那些<<<<<<<、=======、>>>>>>>的行）
• 确认没问题后，提交合并结果即可。这个方法适合偶尔出现这类问题的团队，但需要所有人都清楚怎么处理这种冲突。

方案3：自定义GitFlow合并流程，跳过特定文件合并 #

如果你们团队有自定义GitFlow脚本的能力，可以修改热修复完成的逻辑：

• 在合并hotfix到Master之后，合并到develop时，先单独处理配置文件：

  # 切换到develop分支
  git checkout develop
  # 先cherry-pick热修复的代码，但保留develop的配置文件
  git cherry-pick hotfix/<你的热修复分支名> --strategy=ours -- Dependencies.props
  # 再合并热修复分支的剩余内容
  git merge hotfix/<你的热修复分支名> --no-ff
  

  这样既把热修复的bug代码带到了develop，又不会覆盖develop的NuGet依赖配置。

额外注意事项 #

• 不管用哪种方法，一定要把「哪些文件是环境专属配置」写到团队的Git协作文档里，避免有人误修改或者合并时搞错
• 建议定期同步两个分支的非配置代码，确保除了环境专属内容外，其他代码的一致性

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