发起Pull Request时如何避免合并？git pull -r操作相关疑问

一、发起Pull Request时如何避免提前合并操作 #

如果你不想在本地把master分支合并到自己的开发分支再提交PR，关键是保持自己分支的提交历史独立，只同步master的最新代码但不产生合并提交：

• 别用git merge origin/master把master合并到你的分支，改用git rebase origin/master（或者你提到的git pull -r origin master，本质是一回事），这样你的提交会被“移到”master最新提交的后面，不会生成合并节点，提交历史更干净。
• 发起PR后，大多数代码托管平台都支持直接在平台上选择合并方式（比如rebase合并、squash合并），你不用在本地提前合并，直接提交你的分支就行，平台会处理后续的合并逻辑。

二、git pull -r origin master是不是“仅复制粘贴”？git pull默认行为是什么？ #

先澄清两个常见误解：

1. git pull默认确实会自动合并：它等价于git fetch origin master + git merge origin/master，会生成一个新的合并提交，把master的代码合并到当前分支。
2. git pull -r origin master不是“复制粘贴”，它是git fetch origin master + git rebase origin/master：
   • 这个操作会把你当前分支上的所有提交，基于最新的master重新生成一遍（相当于把你的提交“搬”到master最新代码的后面），不会产生merge类型的提交，但也不是简单的复制粘贴——Git会对比你的提交和master的差异，尝试把你的修改应用到最新的master代码上，如果有冲突还是得手动解决。
   • 别人说的“不进行任何合并”，指的是不会生成merge提交，而不是完全没有代码整合的过程，代码冲突该出现还是会出现，毕竟你的修改和master的最新代码可能有重叠。

三、合并冲突的处理建议 #

如果碰到一堆冲突，试试这些步骤：

1. 先切到master分支，拉取最新代码：

   git checkout master
   git pull origin master
   

2. 回到你的开发分支，执行变基：

   git checkout your-branch
   git rebase master
   

3. 遇到冲突时，Git会提示哪些文件有问题，打开这些文件找到冲突标记（<<<<<<<、=======、>>>>>>>），手动调整代码，保留正确的逻辑。
4. 解决完一个文件的冲突后，执行git add <冲突文件名>，然后git rebase --continue继续变基流程。
5. 如果某一步不想继续变基了，直接用git rebase --abort回到变基前的状态，不会影响你的分支。

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