git pull还是git pull -r？

👋当代码出现冲突的时候，常见流程是：拉取远端最新代码-》解决冲突-》重新推送

标题的答案是优先使用git pull -r

git pull

git pull相当于git fetch + git merge。会创建一个新的合并提交，保留完整的分支历史

git fetch：获取远程最新信息，但不合并

下载最新的代码和分支信息到本地，不会自动合并到你的当前工作分支，工作区代码不会变化

git fetch  # 获取远程仓库的所有更新
git fetch 分支名  # 只获取远程特定分支的更新

git merge：合并分支更改

将一个分支的更改合并到当前所在的分支，相当于 "把别人的新内容融入到自己的工作中"。

• 如果两者修改不冲突，会自动合并成一个新的提交，这个提交同时包含双方的更改
• 如果有冲突，需要你手动选择保留哪些内容，最终形成的版本也是融合了双方正确修改的结果

git merge #合并当前分支的上游分支

git pull -r

git pull -r相当于git fetch + git rebase，会将你的本地提交 "移动" 到远程分支最新提交的后面，形成线性历史

git rebase

将一个分支的修改 “移动” 到另一个分支的最新提交之上，例如master分支上提交内容

• main 分支的时间线：A → B → C（C 是最新的公共提交）
• feature 分支的时间线：从 B 分叉出来，你做了两个提交 D 和 E

A → B → C  （main分支，团队最新）↘D → E  （你的feature分支，基于旧的B开发）

git merge

• 作用：把 main 分支的 C 提交合并到 feature 分支
• 过程：Git 会在 feature 分支创建一个新的 “合并提交 F”，这个提交同时包含 C（别人的修改）和 E（你的修改）
• 最终时间线（出现分叉）：

A → B → C  （main分支）↘   ↖D → E → F  （feature分支，F是合并提交）

保留了分支的分叉历史，能看出 “你是基于 B 开发，后来合并了 C 的更新”

git rebase

• 作用：把你的 feature 分支 “重新嫁接” 到 main 最新的 C 提交上
• 过程：
  1. 先 “暂存” 你的 D 和 E 两个提交
  2. 把 feature 分支 “拉回到” 与 main 同步的 C 提交
  3. 再把暂存的 D 和 E 重新应用到 C 后面（生成新的 D' 和 E'，内容和原来的 D、E 一样，只是基于的基准变了）
• 最终时间线（完全线性）：

A → B → C  （main分支）↘D' → E'  （你的feature分支，现在基于最新的C开发）