如何在分支创建点之前的两个历史提交之间插入新提交？该操作是否符合最佳实践？

一、具体操作步骤 #

针对你描述的场景（要在master分支的A和B之间插入提交X，且B是feature分支的分叉点），可以按照以下步骤操作：

1. 切换到master分支
   首先确保你在目标分支上操作：

   git checkout master
   

2. 启动交互式变基定位到目标位置
   我们需要修改A之后的提交序列，所以用交互式变基指向提交A（也就是B的父提交）：

   git rebase -i <commit-A的哈希值>
   

   在弹出的编辑器里，找到提交B对应的那一行，把开头的pick改成edit，保存并退出。

3. 回退到提交A的状态
   此时Git会把HEAD重置到提交B的状态，我们需要回退一步回到A，这样才能在A之后插入新提交：

   git reset HEAD~1
   

4. 创建新提交X
   现在可以进行你需要的修改（比如.vscode配置调整、代码结构重构），然后提交：

   git add .
   git commit -m "Commit X: 这里写你的提交说明"
   

5. 重新应用原来的提交B
   把之前的提交B应用到X之后：

   git cherry-pick <commit-B的哈希值>
   

6. 完成变基
   继续执行变基，让提交C也应用到新的序列上：

   git rebase --continue
   

   到这里，master分支的历史就变成了 A -> X -> B -> C，和你期望的结构一致。

7. （可选）调整feature分支的基础
   如果希望feature分支也基于新的提交X（让分支起点从A变成X，后续合并更顺畅），可以切换到feature分支执行：

   git checkout your-feature-branch
   git rebase --onto <commit-X的哈希值> <commit-A的哈希值>
   

   这个命令会把feature分支中从A之后的所有提交（D、E）重新放到X的后面，最终分支历史变成 X -> D' -> E'。如果不想调整feature分支，保持原来的A -> D -> E也可以，后续合并master时Git会自动处理（若有冲突则手动解决即可）。

二、关于最佳实践的讨论 #

你的需求很常见——创建feature分支后才发现有些基础修改本该放在master上，这种场景下的操作是否合理，要分情况看：

• 如果master是本地分支（未推送到远程，或仅你自己使用）：修改历史完全没问题，这是高效调整代码结构的方式，只要你清楚操作的影响就可以放心做。

• 如果master已经推送到远程且有其他团队成员协作：修改公共分支的历史是非常不推荐的！因为这会导致其他成员的本地仓库和远程仓库出现历史冲突，需要所有人同步调整，成本很高。这种情况下更稳妥的做法是：

  • 在当前master上新建一个分支，把需要的修改（X）提交到这个分支；
  • 将这个分支合并到master，同时也合并到你的feature分支；
  • 这样既保留了完整的历史记录，又避免了修改公共历史带来的协作混乱。

另外，从流程优化的角度，下次创建feature分支前，可以花几分钟梳理下是否有需要先在master上完成的基础调整，能减少后续修改历史的麻烦。但如果是中途才意识到的需求，只要场景允许（无公共历史冲突），修改历史是完全可以接受的解决方案。

备注：内容来源于stack exchange，提问作者garrofederico