如何线性化 Git 中“分裂的”合并历史？答案

【问题标题】：How to linearize “splintered” merging history in Git?如何线性化 Git 中“分裂的”合并历史？
【发布时间】：2017-04-26 18:59:22
【问题描述】：

我已经阅读了git book 的基础知识，试图将红色分支与合并的蓝色分支线性化。为了更容易回顾历史，我尝试只有一个分支，没有交汇点。我有什么选择可以做到这一点，什么是最好的？

This 回答建议reset --soft，但这里的演示假设它自合并以来增长了很多。可以在af 之前或最好在9c 提交之后将分支蓝色更改添加到红色。

* 5356e62 vimdiff solved
* c1ccf86 red forward
*   51fbd33 Merge branch 'blue' into red
|\  
| * 96575dc new file
| * 1d7f531 some line and blue branch 3
* | 9cc3291 new file
* | 92569c6 another commit
* | f8d3ab2 blue branch 3
|/  
* af8b651 init

【问题讨论】：

标签： git merge rebase cherry-pick

【解决方案1】：

Caveat -- ALL 执行您要求的操作的方法将引用“向后”移动（有效地删除一些提交）；如果这些提交已与其他开发人员共享，则会产生问题。请参阅git rebase 有关从上游变基恢复的文档，并了解虽然这是根据变基记录的，但它适用于所有历史编辑。

如果git reset --soft 是对上一个问题的合理回答，这里也同样合理。

git checkout 5356e62
git reset --soft 9cc3291

现在从 1d7f531 开始的所有更改都显示为阶段性更改，所以

git commit

创建一个将旧提交“压缩”为一个的新提交。

此时如果您有一个指向 96575dc 的分支，那么它将看起来是未合并的。 OTOH，如果父分支以前是唯一可以达到 96575dc 的分支，那么 96575dc 现在无法访问；但如果您不想要详细的历史记录也没关系，因为相关更改在您的新提交中。

更通用的解决方案是merge --squash，更通用的是rebase --interactive

【讨论】：