因此,昨天我在尝试将上游分支重新绑定到我的本地主题分支时发布了一些关于一些奇怪冲突的问题.
最后,我使用git rebase --merge upstream并解决了自上一次rebase以来我没有触及的文件中的大量冲突.
在这种情况下,我对rebase的理解是它将我的提交与该主题分支分离,应用来自上游分支的提交,然后在我的提交之上应用(作为补丁).因此,它最终成为一个快速前进的操作.我不明白的是......为什么我会与来自上游的提交合并冲突.这些也适用于补丁吗?我认为只是......在同一个分支的前一次提交之上"焊接"一些提交的行为?
我问这个是因为我没有触及的文件中有很多冲突.哦,我每天都会对这个上游分支进行重组.
UPDATE
我刚刚注意到从上游到我的主题分支的一些提交已经更改了SHA-1 id.有谁知道Git会对此做些什么?可能是--merge转换?
我的git版本是1.5.6.5
Rebase 重写历史。如果你对已经推送到远程的提交进行变基,你就会进入一个受伤的世界。如果你继续这样变基,情况会更糟。Rebase有时有它的优势,但在我看来,它是一个专业工具,而不是像 merge 那样的休闲工具。
然后将我的提交应用(作为补丁)。
是的,作为新提交
所以,它最终是一个快进操作
不。快进只是移动HEAD该分支的指针。您从远程引入新对象,然后在其上应用补丁。
如果您的本地和远程最后一次同步于A1,并假设您添加了(本地)A2并A3提交,并发现远程已添加B1和B2,则变基将隐藏A2和A3,下拉B1和B2(应该是快进,因为它们共享一个共同的后代A1),然后应用补丁A2并A3 作为新的提交(因此是新的 SHA-1)A2'并且A3'.
所以现在你的本地历史是:
A1 - B1 - B2 - A2' - A3'
这不是快进。
| 归档时间: |
|
| 查看次数: |
2465 次 |
| 最近记录: |