【问题标题】:Conflicts with `git rebase`与`git rebase`冲突
【发布时间】:2010-08-12 08:22:18
【问题描述】:

所以,昨天我发布了一个 question,内容是当我尝试将上游分支重新定位到我的本地主题分支时发生的一些奇怪的冲突。

最后我使用了git rebase --merge upstream,解决了自上次rebase以来我没有接触过的文件中的很多冲突。

在这种情况下,我对 rebase 的理解是,它将我的提交与该主题分支分离,应用来自上游分支的提交,然后将我的提交(作为补丁)应用到这些之上。因此,它最终成为一个快进操作。我不明白的是......为什么我会与来自上游的提交发生合并冲突。那些也作为补丁应用吗?我认为这只是......在来自同一分支的先前提交之上“焊接”一些提交的行为?

我之所以问这个问题是因为我在未接触过的文件中有很多冲突。哦,我每天都用这个上游分支做 rebase。

更新

我刚刚注意到从上游带到我的主题分支的一些提交的 SHA-1 id 发生了变化。有谁知道什么可能导致 Git 这样做?会不会是--merge 开关?

我的 git 版本是 1.5.6.5

【问题讨论】:

  • 你有像stackoverflow.com/questions/1042207/git-svn-rebase-fails这样的自动转换吗?
  • @VonC core.autocrlf 是空白的,我假设它的默认值为“输入”。会不会是因为这个?我不确定现在如何重现该问题,看看将其设置为 false 是否有任何不同。
  • ț:确保将其设置为 false,只是为了确定。
  • 我会的。感谢 VonC,感谢您经常出现并回答 Git 问题 :)

标签: git merge rebase


【解决方案1】:

Rebase 重写历史。如果你对已经推送到远程的提交进行 rebase,那么你将进入一个受伤的世界。如果你继续像这样变基,那就更糟了。 Rebase 有时有它的优势,但它是一个专业工具IMO,而不是一个休闲工具,比如merge。

然后在这些之上应用(作为补丁)我的提交。

是的,作为新的提交

所以,它最终是一个快进操作

没有。快进只是移动该分支的指针HEAD。您正在从远程引入新对象,然后在此之上应用补丁。

如果您的本地和远程最后一次在A1 同步,并且假设您(本地)添加了A2A3 提交,并且发现远程添加了B1B2,那么变基将隐藏A2A3,下拉B1B2(应该是快进,因为它们共享一个共同的后代A1),然后为A2A3 应用补丁作为新提交(因此是新的 SHA-1)A2'A3'

所以现在你的本地历史是: A1 - B1 - B2 - A2' - A3' 这不是快进。

【讨论】:

  • 我知道变基的危险,我不会像那样使用变基。不过,出于某种原因,当我发布这个问题时,我对我没有接触过的文件有奇怪的冲突。众所周知,Rebase 产生的冲突比合并少,但当时对我来说并没有那样的表现。因此我的问题。我还没找到原因,也没有重现。
  • 很好的答案,尤其是最后一段!经验教训:任何变基都意味着所有变基的提交都将具有新的提交 ID。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-06-06
  • 1970-01-01
  • 2011-12-16
  • 2017-07-14
  • 2021-11-09
  • 1970-01-01
相关资源
最近更新 更多