如何调整单分支Git仓库 还原为应有的多分支提交结构

1. 将末尾提交迁移到新建特性分支的实现命令 #

你当前在master分支、HEAD指向最新的commit6时，按顺序执行以下2条命令即可完成目标结构：

• 基于当前最新提交创建特性分支，执行：git branch featurebranch1，此时新建的featurebranch1分支会自动指向commit6
• 将master分支回退到前一个提交（即commit5），执行：git reset --hard HEAD~1

注意：如果你的master分支已经推送到远程仓库、且有其他协作者基于原有线性历史拉取过代码，不要直接执行硬回退操作，否则会导致协作者本地历史与远程不一致，引发同步冲突。这种场景下建议使用git revert生成反向提交抵消commit6的改动，再将commit6的内容挑拣到新分支即可。

执行完成后分支结构就会符合预期：commit1 -> commit2 -> ... -> commit5属于master分支，commit6属于featurebranch1分支。

2. 拆分中间提交到独立特性分支再合并的实用性判断 #

这种操作绝大多数场景下完全不实用，性价比极低。
原因很简单：Git的提交是通过父提交哈希串联的链式结构，如果你要把序列中间的commit2单独抽成featurebranch2分支，那么commit3到commit6所有提交的父哈希都会发生变化，等于你要把后续所有提交全部重写一遍。
要实现你举例的结构，你需要走交互式变基、临时切分分支、拣选后续提交、执行合并操作等一系列繁琐步骤，过程中很容易因为冲突处理不当丢代码，最后得到的代码内容和原来的线性历史没有任何区别，只是提交历史里多了一个形式上的合并节点，属于纯粹为了“历史好看”做的无效操作。
只有一种特殊场景值得做这类操作：你需要为开源项目/正式发布版本整理规范的提交轨迹，且重写后的历史会作为全新的官方基线，要求所有协作者全部基于新基线重新同步本地仓库，这种情况下可以花时间梳理历史。日常协作开发中完全没必要做这类操作，既浪费时间，还会给所有协作者增加不必要的同步成本。

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