混帐拉--rebase

启动情况（不unpushed变化，>表示当前分支）：混帐拉--rebase

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最初？

来源

2011-05-02 Mot

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.

来源

2011-05-02 18:53:56 grzuy

它看起来就像你用'B''混合'B'和'和'C” C' '。不幸的是，实际上，如果'B'和'C'已经是'origin/master'的一部分（由于之前的cherry-pick或rebase），这并不能很好地工作。 – Mot 2011-05-03 04:54:41

'git pull --rebase'与* git fetch不同* git rebase' - 看到[我的答案在下面给出了区别]（http://stackoverflow.com/a/11531552/179332）。 – 2012-07-17 22:43:01

你可以用底垫的合并而不是拉 - 这就是我的团队工作方式，并且工作得很好。

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

由于分支混帐合并的记录合并提交，他们应该是有意义的，例如，以指示功能已被合并到释放科。但是，在常规日常工作流程中，几个团队成员经常同步一个分支，时间轴受到常规git 拉动中的不必要的微合并污染。 Rebasing确保提交始终重新应用，以便历史记录保持线性。

您可以配置一定分行始终做到这一点，而不 --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

来源

2011-10-07 01:29:28 mahalie

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为原来的海报猜到了 - 事实上，它涉及到引用日志（见here如果你的避风港之前没有遇到过这个词）。

对于周围git pull --rebase额外的魔法完整的故事，看到这样的回答：

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

来源

2012-07-17 22:06:52

回答

相关问题