我最喜欢的git工作流程是在提交之前rebase所有内容master，但也要利用git merge --no-ff创建一个历史记录，其中包含可读的、可识别的工作块，以及这些工作块中的精细细节。
使用--no-ff给出的历史记录看起来像这样：
|
|
|
| |FeatureA.InterestingStep1
| |FeatureA.InterestingStep2
| |FeatureA.InterestingStep3
| |FeatureA.InterestingStep4
| |FeatureA.InterestingStep5
| /
|/
|FeatureA
|
|
| |FeatureB.InterestingStep1
| |FeatureB.InterestingStep2
| |FeatureB.InterestingStep3
| /
|/
|FeatureB
没事。
遗憾的是，如果我试图重新定位它，那么我就会失去结构。
假设我已经完成了我的工作，获取，重定基址，清理了合并冲突，清理了我本地混乱的提交历史记录，成为我想要在master上进行的(仍然多个(最终提交，并构建了必要的--no-ff结构。
然后我推了推，但团队中的其他人打败了我，起源\主人已经移动了。 如果我变基，那么-no-ff结构就会消失，我只剩下一个线性提交序列。
重新创建它不是世界末日，但是有没有办法在不丢失结构的情况下重新变基？
你想要的是保留合并提交的-p(或--preserve-merges(rebase选项
从文档中：
重新创建合并提交，而不是通过重播来展平历史记录 提交合并提交介绍。合并冲突解决方案或 不会保留对合并提交的手动修改。
@Francesco的补充 您可能还想注意许多开发人员使用的 git pull --rebase。它也使历史扁平化。避免这种情况的方法是手动进行获取/变基，即(在主服务器上(
git fetch
git rebase --preserve-merges origin/master