与`git rebase`冲突

Question

与`git rebase`冲突

6

所以，昨天我发布了一个问题，关于当我试图将上游分支rebase到我的本地主题分支时出现的一些奇怪冲突。

最终，我使用了git rebase --merge upstream，并解决了许多自上次rebase以来我没有触碰过的文件中的冲突。

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

我问这个问题是因为我在我没有触碰的文件中有很多冲突。哦，而且我每天都使用这个上游分支进行rebase。

更新

我刚刚注意到一些从上游合并到我的主题分支的提交其SHA-1 id已更改。有人知道这可能是Git引起的吗？可能是--merge开关吗？

我的Git版本是1.5.6.5。

- Ionuț G. Stan

你是否有类似于https://dev59.com/gUjSa4cB1Zd3GeqPDCcV的自动转换工具？ - VonC

@VonC core.autocrlf 是空白的，我认为它的默认值是 "input"。这可能是因为这个原因吗？我现在不确定如何重现这个问题，看看将其设置为 false 是否有任何区别。 - Ionuț G. Stan

请确保将其设置为false，以确保安全。 - VonC

1

我会的。感谢VonC一直在这里回答Git相关的问题 :) - Ionuț G. Stan

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- catsby · Accepted Answer

Rebase（变基）会重写历史。如果你对已经推送到远程的提交进行变基，那么你将进入一个麻烦的世界。如果你继续像这样变基，情况会更糟。变基有时有它的优点，但在我看来它是一种专业工具，而不是像合并这样的普通工具。

然后将我的提交（作为补丁）应用于它们之上。

是的，作为新的提交。

所以，这最终变成了快进操作。

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

如果您的本地和远程最后同步在A1处，并且假设您添加了A2和A3提交（本地），并发现远程添加了B1和B2，则变基将存储A2和A3，下载B1和B2（应该是快进，因为它们共享一个公共祖先A1），然后应用A2和A3的补丁作为新的提交（因此新的SHA-1）A2'和A3'。

所以现在你的本地历史记录是：A1-B1-B2-A2'-A3'，这不是一个快进。