需指定合并策略：用 git pull --no-rebase（默认合并）或 git pull --rebase（线性历史），取决于分支用途与团队规范。
git pull 报 fatal: Need to specify how to reconcile divergent branches 怎么办
这是 Git 检测到本地分支和远程分支（如 origin/main）各自有对方没有的提交，无法自动决定用 merge 还是 rebase 整合。它不是错误，而是明确要求你表态。
最直接的解法是加参数执行一次带策略的 git pull：
-
git pull --no-rebase：走默认合并路径，生成一个合并提交，保留双方历史 -
git pull --rebase：把你的本地提交“挪”到远程最新提交之后，形成线性历史
注意：--no-rebase 是默认行为，但某些全局配置（如 pull.rebase=true）会覆盖它，导致不加参数就报错。可临时覆盖：运行 git -c pull.rebase=false pull 等价于 --no-rebase。
怎么判断该 merge 还是 rebase
关键看协作规范和分支用途——不是技术能力问题，而是团队约定问题。
如果你在功能分支（如 feature/login）上开发，且尚未推送到远程，优先选 git pull --rebase。它避免产生无意义的“Merge branch 'main' into feature/login”提交，让后续 git log --oneline 更干净。
如果你在共享分支（如 main 或 develop）上工作，或团队明确要求保留所有合并点，则用 git pull（即 --no-rebase）。此时合并提交本身是有语义的，代表一次集成动作。
容易踩的坑：
使用约定式提交（Conventional Commits）从 Git 历史记录中生成结构化变更日志，支持多种格式、AI 增强型描述以及可自定义的范围……
- 对共享分支执行
rebase后又push --force-with-lease，会破坏他人已 fetch 的本地历史 - 在多人协作的功能分支上盲目
rebase并强制推送，等于重写他人正在基于开发的基础
冲突发生在 rebase 过程中，怎么继续
rebase 不是原子操作，中途遇到冲突时，Git 会暂停并提示你解决。此时不能直接 git commit，也不能 git merge --continue——那是 merge 流程用的。
正确流程只有三步：
- 手动编辑冲突文件，删掉
<<<<<< HEAD、=======、>>>>>>标记，保留正确内容 - 执行
git add <file>标记该文件已解决（必须逐个add，不能git add .跳过） - 执行
git rebase --continue继续应用下一个提交
如果中途想放弃，用 git rebase --abort，一切回到 rebase 前状态。别用 git reset --hard，那会丢掉你自己的提交。
如何提前发现分叉，而不是等 pull 才报警
靠报错被动响应太晚。日常可用两个命令主动探查：
-
git log HEAD..origin/main --oneline：列出远程有、本地没有的提交（别人推了啥） -
git log origin/main..HEAD --oneline：列出本地有、远程没有的提交（你改了啥但还没 push）
两者都非空，就说明已分叉。建议把这两个命令 alias 成 git diffup 和 git diffdown，每次提交前快速扫一眼。
真正容易被忽略的是：分叉本身不等于代码冲突，但它意味着你失去对“当前最新基线”的感知。哪怕只差一个提交，后续 merge 或 rebase 都可能触发意料之外的冲突——尤其当别人改了你正要动的同一块逻辑时。
