为什么在rebase之后，一个pull request会显示额外的提交记录？

Question

为什么在rebase之后，一个pull request会显示额外的提交记录？

gitgithubrebasepull-request

15

所以我从一个提交版本比develop分支领先了几个提交，我们称其为feature分支。

feature分支与develop分支存在一个合并冲突，因此我决定进行变基（rebase）并解决冲突。

git checkout develop git pull
git checkout feature git pull
git rebase develop
解决合并冲突 - 新提交添加
git rebase --continue
变基成功。
git push （我实际上使用的是“同步更改”）

这些步骤之后，在GitHub上的PR从7个提交变成了60+个提交。

我本来期望它只会从7个提交变成8个提交，因为我只解决了一个冲突。

是否有任何想法关于发生了什么以及如何（如果需要）解决？

如果需要，我可以发布其他信息。

编辑，这就是我遇到问题的原因：

请确认您在控制台中使用`git push --force`而不是在VS Code中使用`git sync`按钮：

重新变基后永远不要同步（sync） 要使用`git push --force`！

- Kyek

“Merge conflict fixed” 可能意味着任何事情，甚至可能添加了 180 个提交。请使用 git log 命令检查您的提交树。 - Marco Bonelli

1

如果你正在解决rebase中的冲突，那么你不需要有任何额外的提交，这就是rebase的目的。在解决冲突后只需执行git add <冲突文件>，然后执行git rebase --continue即可。这是正确的吗？ - Prateik Darji

我发现非平凡的变基可以做到这一点。你在推送之前再次执行git rebase develop是否有帮助？ - tripleee

使用命令"gitk --all"或者"git log --all"检查。你可能有一些其他分支，那些分支可能意外地与你的实际提交进行了变基。 - Boris Brodski

3个回答

4

问题可能是你的feature分支可能是从一些不同的分支检出的，比如说test，它已经领先许多次提交。因此，即使您从与您所提出的相同的分支进行了变基，您也会得到提交不一致性。我知道解决这个问题的一种方法是，从develop分支创建一个新分支，并从feature分支挑选所有提交。

- karn

3

以下是可能发生的情况。

当您继续向将被变基的分支添加提交时，可能会出现这种情况。想象一下我们有两个分支master和dev。

master A-B-C
         |
dev      D-E-F

现在我们将dev推送进行审查。
等待审查期间出现了新任务。分支dev得到了新的提交，所以本地看起来像这样：

dev A-B-D-E-F-G

注意，在dev分支中没有C提交。之后，您的拉取请求被接受，并在远程（例如在github上）将您之前的更改合并到了master分支：

master A-B-C-D'-E'-F'

到那时，您将拥有一个从 C 提交开始的已复制 D'-E'-F' 提交的分支 master。但是您的本地 dev 分支不同，它没有 D'-E'-F'，因为它只有 D-E-F。更重要的是，它没有 C 提交。

master A-B-C-D'-E'-F'
dev    A-B-D-E-F-G

现在您想使用rebase将提交G添加到主分支。
两个分支的共同部分是A-B。所以当您进行reabse时，Git无法识别D'和D是相同的，因为它们从不同的点开始（对于dev，它从B开始，对于master，它从C开始）。因此，在新的拉取请求预览中，您将看到不仅提交G，还有D-E-F。

解决方案

快速解决方法是从实际的master创建新分支，例如temp分支。
将新提交内容cherry-pick到temp中。要获取提交的哈希值，只需在dev上尝试git log --oneline命令。

master A-B-C-D'-E'-F'
dev    A-B-D-E-F-G
temp   A-B-C-D'-E'-F'-G

temp 分支包括 master 分支上的所有提交，以及来自 dev 分支的新 G 提交。

[master] git checkout -b temp
[temp]   git cherry-pick 6e687f90 
[temp]   git checkout master
[master] git merge temp

另一种可能的方法是将dev基于master进行变基，并解决所有冲突。然后从dev向master发起拉取请求。如果在dev上有许多重复提交，这可能是一个痛苦的过程。

- Aga

我认为，在我的情况下发生了这种情况。如何修复它？ - prince

我刚刚添加了可能的解决方案。 - Aga

1

另一种可能的方式对我来说很好用。 - Kevin Oswaldo

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

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

- user742599 · Accepted Answer

请查看您所在分支的git日志，并尝试查找任何异常情况。有一条评论提到了使用“git log”，但您也可以使用“git log --graph --oneline”来获得分支提交历史的可视化表示。如果您的分支被正确地rebase，你将看到类似于以下的内容：

* 5eccc30d1 (HEAD -> feature, origin/feature) # Your commit message 8
* 5f73d262a # Your commit message 7
* 6c636b744 # Your commit message 6
* 97e17a7cf # ...
* 596297507 # ...
* 4646ce633 # ...
* 9fb61eb95 # ...
* 38dab17ae # Your commit message 1
*   7532142f7 (origin/develop) Merge pull request #...
|\
| * 042303c7e Add feature
* |   008f1e53b Merge pull request #...
|\ \
| * | 5a398f715 Fix issue with #...
# And so on

将此与其他内容进行比较，尝试找出任何异常之处。您第一次提交下面的提交应该是基本分支，并且在您编写的提交中不应混合其他的提交。

我怀疑在您的特性分支中使用git pull可能存在问题。如果您自己在处理此PR，则不应该有这样的原因，并且可能会出现错误。

如果您需要使用特性分支进行pull，请尝试改用git pull --rebase，它相当于fetch和rebase，而不是fetch和merge。这可以确保您本地提交保持在历史记录的顶部，以防止本地分支和来源之间存在差异。