博文“在 Git 中重新调整合并提交的基础 http://notes.envato.com/developers/rebasing-merge-commits-in-git/" (from 格伦·马德恩 https://github.com/geelen）说明了危险git pull --rebase 当您进行本地合并时:
如果你做一个git pull --rebase of master在之上origin/master现在，你会删除您的本地合并.
rebase 后见下图：不再有合并提交。
出于很多原因，这很糟糕。
- 其一，功能提交实际上是重复的，而实际上我只想对合并进行变基。如果您稍后再次合并功能分支，则两次提交都将出现在历史记录中
master.
- And
origin/feature，应该已经完成并在master，悬空。
与遵循良好的分支/合并模型所获得的令人惊叹的历史不同，您实际上已经获得了误导性的历史。
例如，如果有人看上面的树枝origin，就会出现origin/feature hasn’t已合并到 master 中，尽管它已经合并了！如果该人随后进行部署，可能会导致各种问题。这都是坏消息。
这就是 Github for (Mac|Windows) 会检测并避免的情况。
如果您没有及时检测到，同一篇博文提到了以下恢复：
[master] git reset --hard origin/master
HEAD is now at 9f3e34d sneaky extra commit
[master] git merge --no-ff feature
实际解决方案：
您可以达到想要的结果：
而不是使用git pull --rebase, use a git fetch origin and git rebase -p origin/master
我想“更聪明的版本”pull --rebase是“fetch + rebase 保留合并”的组合。
Glen https://github.com/geelen还提出了以下别名 https://gist.github.com/590895反驳这样一个事实：该命令序列将不再使用与本地分支关联的跟踪信息。
function git_current_branch() {
git symbolic-ref HEAD 2> /dev/null | sed -e 's/refs\/heads\///'
}
alias gpthis='git push origin HEAD:$(git_current_branch)'
alias grb='git rebase -p'
alias gup='git fetch origin && grb origin/$(git_current_branch)'
杰森风化 https://stackoverflow.com/users/3736/jason-weathered发布了一个“http://jasoncodes.com/posts/gup-git-rebase http://jasoncodes.com/posts/gup-git-rebase”，但现在指的是git-up https://github.com/aanand/git-up, from 阿南德·普拉萨德 https://github.com/aanand.
