误直接提交至master分支后，如何合规同步至develop分支？

核心判断依据：master上的提交是否已被其他团队成员拉取/推送至远端 #

情况1：提交仅在本地，未推送至远端或未被他人拉取 #

这是最理想的场景，直接回滚master到与develop一致的状态，再按规范流程开发即可，操作最干净：

• 切换到master分支：git checkout master
• 回滚master到与develop完全一致的状态：git reset --hard develop
• 切换到develop分支，创建合规的feature分支：git checkout develop && git checkout -b feature/your-feature-name
• 将之前在master上的改动重新添加并提交：git add . && git commit -m "你的提交信息"

情况2：提交已推送至远端，且可能被其他成员拉取 #

此时不能用reset（会导致团队成员的仓库版本冲突），需通过cherry-pick迁移提交到合规分支，再按规范合并：

1. 确保你的sync_up_develop_with_master分支是基于最新的develop创建的：
   • 切换到develop拉取最新代码：git checkout develop && git pull
   • 重新基于develop创建feature分支（如果之前的分支不是最新的）：git checkout -b sync_up_develop_with_master
2. 迁移master上的目标提交到该feature分支：
   • 查看master的提交历史，找到需要迁移的commit SHA1：git log master
   • 按提交顺序（从最早到最新）执行cherry-pick：git cherry-pick <commit-sha-1> <commit-sha-2>
   • 如果遇到冲突，解决冲突后执行git cherry-pick --continue即可
3. 推送feature分支并提交PR到develop，等待合并
4. 合并完成后，将develop同步到master：git checkout master && git merge develop

关于merge vs cherry-pick的疑问 #

你看到的文章提到merge更合适，是针对合规分支间的正常合并场景——merge会保留完整的提交历史，避免SHA1重复问题。但在当前场景下，master上的提交属于违规操作，我们需要的是迁移具体的改动而非保留违规的提交历史，因此cherry-pick更合适：它只会把目标提交的改动复制到feature分支，生成新的合规提交，不会把master的违规历史带入develop的PR流程中。

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