将Master分支的新提交迁移回Staging分支的最优方法

首先确认你直接推送到Master的提交已经通过测试、符合上线标准，如果提交还未验证，优先处理Master的异常提交再做同步。下面给出两种适配不同场景的操作方案：

方案1：直接合并Master到Staging（最安全，无历史篡改，适合Master提交已被团队拉取/已部署的场景） #

该方案不会修改现有线上分支的提交记录，不会引发团队成员本地分支和远程分支的不一致问题，操作步骤如下：

• 切换到本地Staging分支，拉取远程最新代码保证本地版本和远程一致

git checkout staging
git pull origin staging

• 执行Master到Staging的合并操作

git merge master

• 若出现合并冲突，解决冲突后执行提交

git add <冲突文件的路径>
git commit

• 推送合并后的Staging分支到远程

git push origin staging

提示：该操作产生的Master反向合并Staging的记录不会影响后续工作流，后续你再从Staging往Master合并代码时，Git会自动识别已经同步的提交，不会产生重复冲突。

方案2：拣选提交+修正Master历史（适合Master误提交未被团队拉取、未部署的场景） #

如果你希望严格遵守Feature Branches -> Staging -> Master -> Deploy的工作流，不出现Master反向合并Staging的记录，可以选择该方案：

• 首先查看Master的提交日志，记录所有直接推送的误提交的哈希值，按提交时间从早到晚排序

git log master --oneline

• 切换到本地Staging分支，拉取最新代码后执行拣选操作，把所有误提交同步到Staging

git checkout staging
git pull origin staging
git cherry-pick <最早的误提交哈希> <第二个误提交哈希> ... <最晚的误提交哈希>

• 拣选无冲突后推送Staging到远程

git push origin staging

• 回滚Master到误提交之前的版本，再走正常的Staging合并到Master的流程

git checkout master
git reset --hard <误提交前最后一个正确提交的哈希>
git push --force origin master # 注意：仅确认所有团队成员都未拉取过带误提交的Master分支时才能执行该操作，执行前必须全团队同步
git merge staging
git push origin master

提示：该方案完全符合你们的工作流规则，但涉及强制推送Master，操作风险更高，必须提前确认团队成员都没有基于错误的Master版本写代码。

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