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 - 这就是我的团队的工作方式,而且效果很好.

从" 你不知道的一些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

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(如果你之前没有遇到过那个术语,请参见此处).

有关额外魔法的完整故事git pull --rebase,请参阅以下答案:

/sf/answers/807205171/

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
|
...

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