git pull --rebase

发布于 2024-11-04 14:49:46 字数 521 浏览 0 评论 0原文

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

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< /code> 经常会产生冲突。 git pull --rebase 是否更聪明，只需使用 git reset 使 master 也指向 E 如果 master==origin/master 最初？

原文

Start situation (no unpushed changes, > indicates the current branch):

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

After a git fetch the log structure often looks like

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

Now git rebase origin/master master often produces conflicts. Is git pull --rebase smarter and just uses git reset to make master also point to E if master==origin/master initially?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

女中豪杰 2024-11-11 14:49:47

git pull --rebase 与 git fetch 不同。 git 变基。不幸的是，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 中额外魔力的完整故事，请参阅此答案：

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

git pull --rebase is NOT the same as git fetch; git rebase. Unfortunately the git-pull man page is rather cryptic about the difference:

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

It turns out that the difference doesn't involve git reset as the original poster guessed - in fact it involves the reflog (see here if you haven't encountered that term before).

For the complete story around the extra magic in git pull --rebase, see this answer:

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

回复收藏 0 原文

寒冷纷飞旳雪 2024-11-11 14:49:47

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 之上重新创建。

git pull --rebase is similar to what the following would do:

git fetch
git rebase

So in your case it will leave the repository like this:

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

Note that the two commits you have are different from origin where re-created on top of commit E.

回复收藏 0 原文

入画浅相思 2024-11-11 14:49:46

您可以使用 rebase 而不是合并来拉取 - 这就是我的团队的工作方式，而且效果很好。

来自“一些你不知道的 git 技巧”：

因为 git 中的分支合并是通过合并提交来记录的，所以它们
应该是有意义的——例如，表明某个功能何时
已合并到发布分支。然而在日常生活中
多个团队成员经常同步单个分支的工作流程，
时间线被常规 git 上不必要的微合并污染
拉。变基确保始终重新应用提交，以便
历史保持线性。
您可以将某些分支配置为始终执行此操作，而无需
--rebase 标志：
#make 'git pull' 在 master 上始终使用 rebase
$ git configbranch.master.rebase true
您还可以设置一个全局选项来设置
每个新跟踪分支的最后一个属性：
# 为每个跟踪分支设置变基
$ git config --globalbranch.autosetuprebase 始终