启动情况（没有未推送的更改，>表示当前分支）：
o C [> master][origin/master]
|
o B
|
o A
|
...
git fetch日志结构通常看起来像
o E [origin/master]
|
o C'
|
o B'
|
o D
|
| o C [>master]
| |
| o B
|/
o A
|
...
现在git rebase origin/master master经常产生冲突。是否git pull --rebase更聪明，并且仅用于git resetmakemaster也指向Eif master==origin/master最初？
您可以使用 rebase 而不是合并来拉取——这就是我的团队的工作方式，而且效果很好。
来自“一些你不知道的 git 技巧”：
因为 git 中的分支合并是与合并提交一起记录的，所以它们应该是有意义的——例如，表明一个特性何时被合并到一个发布分支。但是，在几个团队成员经常同步单个分支的日常工作流程中，时间线会被常规 git pull 上不必要的微合并污染。变基可确保始终重新应用提交，以使历史保持线性。
您可以将某些分支配置为始终在没有 --rebase 标志的情况下执行此操作：
#make 'git pull' on master always use rebase
$ git config branch.master.rebase true您还可以设置一个全局选项来为每个新跟踪的分支设置最后一个属性：
# setup rebase for every tracking branch
$ git config --global branch.autosetuprebase always
git pull --rebase不一样。_ git fetch; git rebase不幸的是，git-pull手册页对差异相当神秘：
--rebase
Rebase the current branch on top of the upstream branch
after fetching. If there is a remote-tracking branch
corresponding to the upstream branch and the upstream branch
was rebased since last fetched, the rebase uses that
information to avoid rebasing non-local changes.
事实证明，差异并不git reset像原始发布者所猜测的那样涉及 - 实际上它涉及reflog（如果您之前没有遇到过该术语，请参见此处）。
有关额外魔法的完整故事git pull --rebase，请参阅以下答案：
git pull --rebase类似于以下内容：
git fetch
git rebase
因此，在您的情况下，它将像这样离开存储库：
o C [> master]
|
o B
|
o E [origin/master]
|
o C'
|
o B'
|
o D
|
o A
|
...
请注意，您拥有的两个提交与origin在提交 E 之上重新创建的提交不同。