git pull --rebase

Question

开始情况（没有未按下的更改，>表示当前分支）：

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 reset == master最初只使用E使master也指向origin/master？

Answer 1

你可以使用rebase而不是merge - 这就是我的团队的工作方式，而且效果很好。

来自“A few git tips you didn't know about”：

  

因为git中的分支合并是用合并提交记录的，所以它们   应该是有意义的 - 例如，指示一个功能   已合并到发布分支。但是，每天定期   几个团队成员经常同步一个分支的工作流程   时间线受到常规git上不必要的微合并的污染   拉。重新启用可确保始终重新提交提交   历史保持线性。

     

您可以将某些分支配置为始终执行此操作而不使用   --rebase flag：

     

#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

Answer 2

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 （如果您没有遇到过，请参阅here之前的那个词。）

关于git pull --rebase中额外魔法的完整故事，请参阅以下答案：

https://stackoverflow.com/a/11531502/179332

Answer 3

git pull --rebase类似于以下内容：

git fetch
git rebase

所以在你的情况下它会像这样离开存储库：

o C [> master]
|
o B
|
o E [origin/master]
|
o C'
|
o B'
|
o D
|
o A
|
...

请注意，您提交的两个提交与在提交E之上重新创建的origin不同。