与`git rebase`冲突 [英] Conflicts with `git rebase`
问题描述
a>关于一些奇怪的冲突，当我尝试将上游分支重新绑定到本地主题分支中时。
最后，我使用 git rebase - 合并上游，并解决了自上一次rebase以来未触及过的文件中的很多冲突。
我在这种情况下了解rebase是它将我的提交从该主题分支中分离出来，应用来自上游分支的提交，然后在我的提交之上应用（作为补丁）我的提交。所以，它最终是一个快速前进的操作。我不明白的是......为什么我会将冲突与来自上游的犯罪相结合。这些也是作为补丁应用吗？我认为只是......在前一次提交之前焊接了一些提交的行为，而这个提交来自同一个分支？
我问这个是因为我在我没有碰过的文件中有很多冲突。 哦，我每天都会对这个上游分支进行rebase。
更新
我刚刚注意到，从上游带到我的主题分支的一些提交已将其SHA-1标识更改。有谁知道可能会导致Git做到这一点？它可能是 - merge 开关？ 我的git版本是1.5.6.5
重新编写历史记录。如果你重新提交已经被推送到遥控器的提交，你正在进入一个受到伤害的世界。更糟糕的是，如果你继续像这样改版。 Rebase具有时间优势，但它是一个专门的工具IMO，而不是一个随便的工具，比如合并。
然后应用（作为补丁）我在这些提交之上的提交。
是，作为新提交
因此，它最终是一个快进操作
没有。快进只需移动该分支的指针 HEAD 。您正在从远程引入新对象，然后在其上应用修补程序。
如果您的本地和远程用户在 A1 上保持同步，并说您添加了（本地） A2 和 A3 提交，发现远程已经添加了 B1 和 B2 ，rebasing将存入 A2 和 A3 ，下拉 B1 和 B2 （应该是快进，因为它们共用一个共同的后代 A1 ），然后针对 A2 和 A3 应用补丁作为新提交 strong>（因此是新的SHA-1） A2'和 A3'。
所以现在您的本地历史是：
A1 - B1 - B2 - A2' - A3'
这不是快进。
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
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.
and then applies (as patches) my commits on top of those.
Yes, as new commits
So, it ends up being a fast-forward operation
No. A fast-forward is simply moving the pointer HEAD of 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) A2 and A3 commits, and found that the remote had added B1 and B2, rebasing will stash A2 and A3, pull down B1 and B2 (should be a fast-forward since they share a common descendant A1), and then apply patches for A2 and A3 as new commits (hence new SHA-1) A2' and A3'.
So now your local history is:
A1 - B1 - B2 - A2' - A3'
which is not a fast-forward.
这篇关于与`git rebase`冲突的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
