Gitflow工作流：如何将热修复从master同步至development分支？

首先得把你遇到的PR diff满是无关文件的原因说透：当你直接从hotfix分支向dev发起PR时，GitHub的diff是对比hotfix分支的HEAD和dev分支的HEAD的所有差异，而不是只展示hotfix上新增的变更。这是因为hotfix是从master拉出来的，而dev和master大概率已经分叉了——dev上有很多master没有的新功能，master上也可能有之前的热修复或稳定版变更，两者的共同祖先比较旧，diff自然会把这些分叉后的所有差异都列出来，而不只是你这次hotfix的内容。

接下来是同步hotfix到dev的最佳实践，分两种场景：

首选方案：合并master到development #

既然hotfix已经合并到master了，最稳妥也最符合分支管理逻辑的方式，就是把master的内容同步到dev：

• 本地操作步骤：
  1. 切换到dev分支：git checkout development
  2. 拉取最新的dev代码：git pull origin development
  3. 合并master分支：git merge master
  4. 处理可能出现的冲突（如果有的话），提交变更：git add . && git commit -m "Merge master (including hotfix XXX) into development"
  5. 推送到远程仓库：git push origin development
• 如果你习惯用GitHub PR操作，直接从master分支向development发起PR就行——这时候的diff只会展示master和dev之间的差异，其中就包含了你刚合并的hotfix内容，不会有多余的“假变更”。

这个方案的好处是：既同步了hotfix，也让dev和master的差异保持最小，避免后续合并dev到master时出现大量冲突，完全符合分支管理的设计逻辑。

备选方案：Cherry-Pick热修复提交到development #

如果因为特殊原因，你不想把master上的其他变更（比如之前的旧热修复）同步到dev，那可以用cherry-pick把hotfix上的单个或多个提交移植到dev：

• 先找到hotfix上的提交哈希值：git log hotfix，复制你需要的提交ID
• 切换到dev分支：git checkout development
• 拉取最新代码：git pull origin development
• 执行cherry-pick：git cherry-pick <提交哈希>（如果有多个提交，按顺序逐个执行）
• 处理冲突后提交，推送到远程
• 之后可以从本地cherry-pick后的分支向远程dev发起PR

⚠️ 注意：这个方案要谨慎使用，因为cherry-pick会创建新的提交ID，后续合并master到dev时，Git可能会认为这些是新的变更，导致重复冲突。除非你确定dev短期内不会合并到master，否则尽量用第一种方案。

总结一下：直接从hotfix到dev发PR是不太合理的，分支来源差异会导致diff混乱。首选合并master到dev，既干净又符合分支策略；特殊情况再考虑cherry-pick。

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