Git push前未git pull导致fork仓库提MR出现合并冲突如何解决

方案可行性确认 #

你提到的先同步本地master与上游master，再合并到update分支的操作完全可行，是处理这类fork仓库MR冲突的标准方案之一。如果你希望自己的提交完全放在上游最新提交之上，更推荐使用变基（rebase）操作，最终的提交历史会更整洁线性。

冲突原因补充说明 #

缺少上游的commit3、commit4是触发冲突的最常见原因，除此之外如果你的commit5、commit6修改的文件/代码行，和上游这两个新提交的改动范围重叠，哪怕你同步了上游代码，仍然需要手动解决对应冲突，这属于正常情况，同步操作不会自动解决代码内容层面的冲突。

具体操作步骤 #

前置准备：配置上游仓库 #

首先确认本地已添加上游远程仓库：

git remote -v

如果输出中只有你自己fork仓库的origin地址，执行命令添加上游仓库：

git remote add upstream <上游仓库的Git地址>

步骤1：同步上游最新代码到本地和你的origin仓库 #

# 切到本地master分支
git checkout master
# 拉取上游master的最新改动
git pull upstream master
# （可选）同步到你自己fork的origin仓库的master分支
git push origin master

步骤2：更新你的update分支 #

这里提供两种方案，按需选择：

方案A：合并模式（就是你设想的操作，操作门槛低）

# 切到update分支
git checkout update
# 把同步过上游的本地master改动合并到update分支
git merge master

如果提示冲突，按照命令行提示打开对应冲突文件，手动修改冲突内容后执行git add <冲突文件名>，再执行git commit完成合并即可

合并完成后推送到你的origin仓库：

# 因为远程已有旧的update分支，需要加-f强制推送（仅在自己的私有功能分支使用该参数）
git push -f origin update

推送完成后你之前提交的MR会自动更新，不需要重新提交。

方案B：变基模式（实现「你的提交放在上游最新提交之上」的需求，提交历史更整洁）

# 切到update分支
git checkout update
# 执行变基，将你的commit5、commit6移动到上游最新master的末尾
git rebase master

如果遇到冲突，修改完冲突文件后执行git add <冲突文件名>，再执行git rebase --continue直到变基完成；如果中途想放弃变基，执行git rebase --abort即可回到操作前的状态

变基完成后强制推送：

git push -f origin update

推送完成后MR自动更新，提交历史会显示上游的commit3、commit4在前，你的commit5、commit6紧随其后，完全符合你的要求。

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