Git环境下生产热修复不影响开发的策略及cherry-pick方案问询

最优无侵入修复策略 #

最适合团队协作场景的标准修复方案不会改动现有master分支上已有的未完成开发提交，流程如下：

• 从生产环境对应的提交A直接切出独立的hotfix临时分支
• 在hotfix分支上完成修复代码D的开发和测试，验证通过后合并到master分支，直接部署到生产环境
• 同时将D cherry-pick到后续开发的基准分支，避免后续开发版本复现该故障

这个方案完全不需要修改已经合入master的B、C提交，对现有开发进度零影响，也不会引发团队成员本地分支和远程分支的历史冲突。

你构思的方案可行性说明 #

你提到的先回退master到A、提交D后再cherry-pick B、C的方案仅适用于单人开发、无其他人员协同使用master分支的场景，如果是多人协作的团队不建议使用，存在以下风险：

• 所有已经拉取过包含B、C的master分支的开发者，本地提交历史会和远程回退后的master分支产生冲突，需要所有人手动处理历史，极易出现代码丢失
• 如果B、C之上已经有新的后续开发提交，cherry-pick的工作量会大幅提升，还可能出现提交遗漏

调整提交顺序的实现方法 #

首先需要澄清：将D插入A和B之间的话，最终提交顺序是A -> D -> B -> C，如果需要的是D在B、C之后的A -> B -> C -> D顺序，直接在当前master顶端提交D即可，无需修改历史。

如果确实需要将D插入到A和B之间调整提交序列，可以通过git交互式变基实现，操作步骤如下：

1. 先基于提交A创建临时分支提交D，记录D的提交哈希值
2. 切换到master分支，保证工作区干净，执行git rebase -i <A的提交哈希值>
3. 弹出的交互式编辑界面中，第一行新增pick <D的提交哈希值>，保存后退出
4. 按照提示解决可能出现的冲突，冲突解决后执行git rebase --continue即可完成提交顺序调整

注意：该操作属于变基操作，会修改B、C的提交哈希值，如果你已经将B、C推送到了公共远程仓库，调整后需要执行git push --force强制推送，会影响所有协同使用该分支的开发者，非必要不建议在公共分支上执行该操作。

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