GitHub无法将我的功能分支rebase：“由于冲突，无法对此分支进行rebase”。

Question

即使我的特性分支是从最新版本的main分支创建的，当我尝试将我的PR（从特性X到main）进行rebase时，我最终看到的是： 由于冲突，无法对该分支进行rebase操作 由于在重新应用来自头部分支的各个提交时遇到冲突，因此无法自动执行将这个分支的提交rebase到基础分支上的操作。

我知道可以通过以下方式解决这个问题：

git checkout main
git rebase feature/x
(resolve conflicts)

然而，直接推送到main是被锁定的，我需要通过PR进行操作。成功地将feature/x分支变基到main的步骤是什么？

- Jay

Answer 1

如果你是从main创建了分支，但现在需要将其变基到main上，那么main在你创建分支后肯定已经更新过了。冲突就是由于这些变更引起的。

I understand that this can be resolved by:

git checkout main
git rebase feature/x
(resolve conflicts)

这不正确。这将把main重新基于feature/x；你需要将feature/x基于main。

相反，

1. 在重新基于之前，从GitHub更新你的本地main，通过pull或类似方式，
2. 检出feature/x，
3. 运行git rebase main，并且
4. 解决冲突。

然后将你的特性分支推送到GitHub（由于这会重写提交哈希值，所以你需要使用--force-with-lease）。拉取请求将相应更新。

- Chris

---

使用 --force-with-lease 命令会让您获得一次点赞。 - jub0bs

在上述第4步之后：

5. 你可能需要执行：git rebase --continue 不要提交，然后你可以按照上面提到的使用 --force-with-lease 最终推送。

- Lekia

Answer 2

首先让我们看一下是什么原因导致了这个问题，从问题中可以得出以下信息：

这个分支无法进行变基操作，因为在将这个分支的提交放到基础分支之上时遇到了冲突。由于在重新应用每个提交时遇到了冲突，因此无法自动执行对这个分支的提交进行变基操作。

当无法将每个单独的提交干净地变基到主分支上时，就会出现这种情况。

例如，如果一个PR存在合并冲突，并且通过合并主分支并修复冲突来解决了这些冲突，那么这个警告不会受到影响，因为GitHub不允许对PR进行干净的变基操作。

请注意，所有解决方案都涉及重写PR分支的历史记录，并通过GitHub的用户界面进行合并。

使用git rebase修复问题

如果您希望保留所有单独的提交：

$ cd /my/repo
$ git checkout my-feature-branch
$ git fetch
$ git rebase origin/main             # 1
$ git push -f origin/my-feature-branch # 2

这将会做以下几件事情：

1. 在主分支上重新应用每个提交到PR中
2. 更新GitHub上的PR分支

如果一个PR有大量的提交，这个过程可能会很痛苦 - 肯定会有至少一个合并冲突需要解决（否则，GitHub就不会在PR上显示警告(: ) - 如果你开始了这个过程后发现是错误的操作，可以使用git rebase --abort回到一个干净的工作副本。

使用git rebase -i修复

如果你希望保留所有/大部分单独的提交并进行调整：

$ cd /my/repo
$ git checkout my-feature-branch
$ git fetch
$ git rebase origin/main -i          # 1
$ git push -f origin/my-feature-branch # 2

这将会做以下几件事情：

1. 在主分支上交互式地重新基于每个PR中的提交链接1
2. 更新GitHub上的PR分支

如果你意识到通过合并一些提交、重新排序提交等方式可以得到一个清晰的历史记录，那么这将非常方便。

同样，如果你开始了这个过程后发现是错误的决定（或者想再试一次），可以使用git rebase --abort回到一个干净的工作副本。

使用git reset修复

如果你不关心保留单独的PR提交，还有一个更简单/更容易的选择：

$ cd /my/repo
$ git checkout my-feature-branch
$ git fetch
$ git merge origin/main                # 1
$ git reset --soft origin/main         # 2
$ git commit -va                       # 3
$ git push -f origin/my-feature-branch # 4

这将会做以下几件事情：

1. 确保分支与 origin/main 分支保持最新
2. 重置本地分支以匹配 origin/main（但不修改工作副本）
3. 为 PR 创建一个新的单一提交（这是一个新的提交，请记得写一个详细的提交信息！）
4. 更新 GitHub 上的 PR 分支

这个过程不需要你解决中间冲突。

未来避免

Github 允许 多种合并策略用于 PR：

问题在于问题只针对rebase和merge，所以为了避免：就不要使用/强制使用rebase和merge策略。

- AD7six

Answer 3

如果您在使用GitHub在线/网页时来到这里，可能有一个更快更简单的解决方案：

如果您已经：

1. 按照通常的方式提出了PR（拉取请求），
2. 已经获得批准，但是
3. 您看到的消息是“由于冲突，无法对此分支进行变基”，而不是通常的绿色合并按钮。没有像通常一样的绿色合并按钮。
4. 如果您的默认合并设置是变基而不是压缩。

这并不明显，但您可以点击UI中GIT消息旁边的内容，它将显示其他合并类型（绿色按钮）。

您可以选择压缩，这将丢失您迄今为止所做的各个提交，但这将使您的PR进入存储库。

- CyclingDave

Answer 4

只需关闭并重新打开拉取请求即可。这对我有效。

- Venky

---

谢谢！我来这里是因为收到了一条关于PR的消息，它已经与主分支保持最新状态（比主分支领先2个提交，没有落后），有18行代码发生了变化（而且不是特别长的行）。所以，关于如何rebase的建议并不是特别有帮助。改变合并策略也不是一个好的选择 - 有很多原因可能需要使用rebase和merge策略（分支需要线性历史，但你想保留PR中逻辑上独立部分之间的分离）。 - Adam Azarchs

Answer 5

重置操作步骤：

x@xyz-pc:~/workspace$ git branch

• xyz分支

  主分支

x@xyz-pc:~/workspace$ git checkout 主分支

切换到主分支

你的分支已经是最新的。

x@xyz-pc:~/workspace$ git branch

• 主分支

  xyz分支

x@xyz-pc:~/workspace$ git pull

正在更新...... 快进中....

x@xyz-pc:~/workspace$ git pull

已经是最新的。

x@xyz-pc:~/workspace$ git checkout xyz分支

切换到xyz分支

x@xyz-pc:~/workspace$ git branch

• xyz分支

  主分支

x@xyz-pc:~/workspace$ git rebase 主分支

首先，回滚头部以便在其之上重新播放你的工作......

将xyz分支快进到主分支。

冲突场景：

x@xyz-pc:~/workspace$ git rebase main

- 如果没有冲突，那么rebase成功，并会显示更新的消息。 - 如果出现错误，您需要解决冲突，'git status'将显示冲突的文件如下所示：

x@xyz-pc:~/workspace$ git status

正在进行rebase； ..... 未合并的路径：

    both modified:   conflicting-file

它会显示未合并路径下的冲突文件。

解决该文件并提交，然后执行 'git rebase --continue'。

- kavita