即使当我的功能分支从最新版本的分支出来时master,当我尝试重新建立PR(从功能X到主版本)的基础时,我仍然看到:
由于发生冲突,无法重新建立 该分支的基础,由于在从head分支重新应用单个提交时遇到冲突,因此无法在基础分支之上自动执行该分支的提交。
我了解可以通过以下方式解决此问题:
git checkout master
git rebase feature/x
(resolve conflicts)
但是,直接推到master已锁定,我需要进行PR。feature/x通过拉取请求成功能够将分支重新建立为master 的步骤是什么?
AD7*_*six 24
首先我们从问题来看是什么导致了这个问题:
由于冲突,此分支无法变基 由于在从头分支重新应用各个提交时遇到冲突,因此无法自动执行在基础分支之上的此分支的提交变基。
当无法将每个单独的提交干净地重新设置到 main 上时,就会发生这种情况。
例如,如果 PR 存在合并冲突,并且通过合并 main 并在新提交中修复冲突来解决这些冲突,则不会对此警告产生任何影响,因为它不允许 GitHub 干净地重新建立 PR 基础。
请注意,所有解决方案都涉及重写PR 分支的历史记录并通过 GitHub 的 UI 进行合并。
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
这会:
如果 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
这会:
例如,如果您认识到通过将一些提交压缩在一起或重新排序提交等可以获得干净的历史记录,这会很方便。
再说一次,如果您开始此过程并确定这是错误的举动(或想重试)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
这会:
此过程不需要您解决中间冲突。
Github 允许PR 的多种合并策略:
问题中的问题仅特定于rebase and merge,因此要避免:只是不要使用/强制变基和合并策略。
Chr*_*ris 11
如果您从创建分支,master但是现在需要重新建立基础,master那么master自创建分支以来,必须已对其进行了更新。冲突来自这些变化。
我了解可以通过以下方式解决此问题:
Run Code Online (Sandbox Code Playgroud)git checkout master git rebase feature/x (resolve conflicts)
这是不对的。这将重订master到feature/x; 你需要重订feature/x到master。
代替,
master在重新设置基准之前,通过GitHub pull或类似方法从GitHub 更新本地,feature/x出,git rebase master,并然后将功能分支推送到GitHub(您需要使用它,--force-with-lease因为这会重写提交哈希值)。拉取请求将相应更新。
| 归档时间: | 
 | 
| 查看次数: | 2994 次 | 
| 最近记录: |