嘿，我来帮你理清楚后续正确的操作流程——你之前撤销合并提交的做法是对的，现在按下面的步骤来就能顺利解决冲突并完成PR：

1. 先同步本地master到最新状态 #

首先切换到master分支，拉取远程仓库的最新代码，确保你要合并的是最当前的master版本：

git checkout master
git pull origin master

2. 切回功能分支，执行master合并 #

切换回你的功能分支（假设分支名为feature/your-function），然后执行合并操作：

git checkout feature/your-function
git merge master

执行完这步后，Git会检测到冲突并提示你进入冲突解决状态。

3. 手动解决代码冲突 #

打开所有标记为冲突的文件，你会看到Git自动添加的冲突标记：

<<<<<<< HEAD
# 这部分是你功能分支上的代码
=======
# 这部分是master分支上的代码
>>>>>>> master

仔细对比两段代码的逻辑，结合业务需求保留正确的实现（如果拿不准，记得和团队里负责对应模块的同事沟通），然后删除所有冲突标记（<<<<<<<、=======、>>>>>>>）。

4. 标记冲突已解决并提交合并结果 #

冲突文件修改完成后，用Git标记这些文件已处理完毕：

git add <冲突文件名>

如果有多个冲突文件，也可以用git add .（注意确保只添加冲突相关的修改，别误加其他未改动的文件）。

接着提交合并结果：

git commit

此时Git会自动生成默认的合并提交信息，你可以直接保存退出，或者根据需要自定义提交内容。

5. 推送功能分支到远程仓库 #

把处理完冲突的功能分支推送到远程：

git push origin feature/your-function

如果之前你已经推送过该分支，且撤销合并的操作导致本地分支与远程分支存在历史差异，建议用更安全的强制推送命令（避免覆盖他人的改动）：

git push --force-with-lease origin feature/your-function

--force-with-lease会先检查远程分支是否有你未同步的新改动，比直接用--force更安全。

6. 完成Pull Request #

现在你的功能分支已经包含了最新的master代码，且所有冲突都已解决，回到代码托管平台（GitHub/GitLab等）：

• 如果之前已经发起过PR，平台会自动识别到你推送的新代码并更新PR状态；
• 如果还没发起PR，直接创建从功能分支到master的PR即可。

额外小贴士 #

• 建议在开发过程中定期将master合并到功能分支（比如每周1-2次），避免到PR时积累大量冲突，增加处理难度；
• 解决完冲突后，最好本地跑一遍测试用例，确保代码逻辑正常，没有引入新bug；
• 复杂冲突不要硬扛，及时和团队成员沟通确认，避免因为错误处理冲突导致后续问题。

内容的提问来源于stack exchange，提问作者yrslvrtfmv