与“git rebase”冲突
所以，昨天我发布了一个问题当我尝试将上游分支重新设置为本地主题分支时，出现了一些奇怪的冲突。
最后我使用了 git rebase --merge upper 并解决了自上次 rebase 以来我没有触及过的文件中的许多冲突。
在这种情况下，我对变基的理解是，它将我的提交与该主题分支分离，应用来自上游分支的提交，然后将我的提交应用（作为补丁）在这些提交之上。因此，它最终成为一个快进操作。我不明白的是......为什么我会与来自上游的提交发生合并冲突。这些也作为补丁应用吗？我认为这只是......在来自同一分支的上一个提交之上“焊接”一些提交的行为？
我问这个问题是因为我在未触及的文件中存在很多冲突。哦，我每天都会与这个上游分支进行变基。
更新
我刚刚注意到从上游带到我的主题分支的一些提交的 SHA-1 id 已更改。有谁知道什么会导致 Git 这样做？可能是 --merge 开关吗？
我的git版本是1.5.6.5
So, yesterday I posted a question regarding some weird conflicts when I tried to rebase an upstream branch into my local topic branch.
In the end I used git rebase --merge upstream and solved a lot of conflicts in files I haven't touched since the previous rebase.
My understanding of rebase in such a case is that it detaches my commits from that topic branch, applies the commits from the upstream branch, and then applies (as patches) my commits on top of those. So, it ends up being a fast-forward operation. What I don't understand is... why would I have merge conflicts with those commits that come from upstream. Are those applied as patches as well? I thought is just... the act of "welding" some commits on top of the previous commit that came from the same branch?
I'm asking this because I had a lot of conflicts in files I haven't touched. Oh, and I do daily rebases with this upstream branch.
UPDATE
I've just noticed that some of the commits brought from the upstream to my topic branch have their SHA-1 id changed. Does anyone know what could cause Git do to this? Could it be the --merge switch?
My git version is 1.5.6.5
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Rebase 重写历史。如果你对已经推送到远程的提交进行变基，你就会进入一个受伤的世界。如果你继续这样变基，情况会更糟。 Rebase 有时有它的优势，但在我看来，它是一种特殊工具，而不是像合并那样的休闲工具。
是的，作为新提交
否。快进只是移动该分支的指针
HEAD。您从远程引入新对象，然后在其上应用补丁。如果您的本地和远程上次在
A1同步，并假设您添加了（本地）A2和A3提交，并发现远程已添加B1和B2，变基将隐藏A2和A3，下拉B1> 和B2（应该快进，因为它们共享共同的后代A1），然后为A2和应用补丁A3作为新提交（因此是新的 SHA-1）A2'和A3'。所以现在你的本地历史是：
A1 - B1 - B2 - A2' - A3'这不是快进。
Rebase re-writes history. If you rebase commits that have already been pushed to a remote, you are entering a world of hurt. Even worse if you continue to rebase like this. Rebase has it's avantages at times, but it is a specialty tool IMO, not a casual tool, like merge.
Yes, as new commits
No. A fast-forward is simply moving the pointer
HEADof that branch. You are introducing new objects from remote and then applying patches on top of that.If your local and remote were last in sync at
A1, and say you added (locally)A2andA3commits, and found that the remote had addedB1andB2, rebasing will stashA2andA3, pull downB1andB2(should be a fast-forward since they share a common descendantA1), and then apply patches forA2andA3as new commits (hence new SHA-1)A2'andA3'.So now your local history is:
A1 - B1 - B2 - A2' - A3'which is not a fast-forward.