git pull报divergent branches不是错误，而是提醒本地与远程分支已分叉，需指定合并（git merge）或变基（git pull --rebase）策略来协调历史。
远程分支协同出问题，90% 不是 Git 坏了，而是本地和远程历史不一致，必须先同步再操作——跳过 git pull 或 git fetch 直接 git push，几乎必然被拒。
看到 [rejected] main -> main (non-fast-forward) 怎么办
这是 Git 在告诉你：远程 main 有你本地没有的提交（比如同事刚推了一个修复），它拒绝“覆盖式推送”，防止丢代码。
- 立刻运行
git pull origin main（等价于git fetch origin+git merge origin/main） - 如果提示
CONFLICT (content)，说明改了同一文件的同一区域，得手动处理 - 别用
git push --force硬顶——它会删掉远程那条新提交，可能抹掉别人刚合入的关键逻辑 - 若你确定要丢本地修改，可用
git fetch origin && git reset --hard origin/main，但务必确认没人依赖你未推送的 commit
git pull 报 divergent branches 是什么信号
说明你和远程分支从某个共同祖先开始，各自提交了互不包含的更改，Git 不知道该以谁为基准合并。
- 这不是错误，是提醒你做选择：用
git merge保留双方历史（生成 merge commit），或用git pull --rebase把你的提交“重放”到远程最新基础上（线性历史） - 如果只是临时协作分支（如
feature/login），推荐git pull --rebase，避免无意义的 merge 提交 - 执行
--rebase后若遇冲突，解决后用git add <file></file>+git rebase --continue，不是git commit
冲突文件里看到 和 <code>>>>>>> origin/main 怎么删才安全
这些标记不是装饰，是 Git 划出的决策边界。删错会导致语法错误、逻辑重复，甚至功能倒退。
- 先确认
HEAD部分是你当前分支的修改，origin/main部分是远程分支的修改，中间======是分隔线 - 不能只删标记、留两段代码——哪怕看起来“都对”，也得选一个逻辑路径，把另一段整块删干净
- 改完保存后，必须
git add <file></file>，否则 Git 仍认为该文件处于冲突状态，后续git commit会被拦住 - 别信 IDE 的“自动解决”按钮——有些编辑器在暂存区混乱时会误判，
git status才是唯一可信源
git status 不显示冲突文件，但 git pull 明明报错了
常见于文件已被 Git 跟踪但规则写错，或者缓存没刷新，导致 Git 认为“没问题”，其实忽略了关键冲突点。
- 运行
git diff --name-only --diff-filter=U，它强制列出所有未合并（unmerged）的文件，比git status更底层、更可靠 - 如果怀疑
.gitignore生效异常，先执行git ls-files --others --ignored看哪些本该忽略的文件被列出来了 - 已跟踪文件改了
.gitignore不会自动失效，需手动git rm --cached <file></file>再git add <file></file>
真正容易被忽略的是：冲突从来不只是文本标记的问题。它背后是两个人对同一段逻辑的理解差异。删标记只是动作，决定哪段代码该活下来，才是协同的本质——Git 只暂停，不替你做判断。
