git pull失败提示冲突并非网络问题，而是因本地与远程修改同一文件同一位置，git拒绝自动覆盖；需用git status查看冲突文件，手动删除> origin/main标记并保留正确代码，再执行git add和git commit（或git merge --continue）解决。
能同步，但“同步”不是一键操作，而是由明确动作驱动的双向过程：你主动 push 才把本地提交发出去，主动 pull 或 fetch 才把远程更新拿回来。
为什么 git pull 有时会失败并提示冲突
这不是网络问题，而是 Git 拒绝自动覆盖你的修改。典型触发场景包括：
- 你改了
src/utils.js，同事也改了同一行，然后先推到了远程 - 你删了
README.md，同事却在远程仓库里编辑了它 - 你用
git commit保存了修改，但还没push，此时远程已有新提交
Git 会在冲突文件中插入三段标记：（你的版本）、<code>=======（分隔线）、>>>>>> origin/main（远程版本）。必须手动删掉这些标记、保留正确逻辑，再 git add 和 git commit 才算解决。
git push 被拒绝：常见原因和对应操作
最常遇到的是 rejected - non-fast-forward。这意味着远程分支有你本地没有的提交，Git 不允许直接覆盖——这是保护机制，不是错误。
- 如果你确认本地改动不重要：先
git fetch origin，再git reset --hard origin/main（⚠️会丢弃所有未推送的本地提交） - 更安全的做法：执行
git pull --rebase origin main，把你的提交“重放”到远程最新基础上，避免合并提交污染历史 - 极少数情况需强制推送（如修复错推的敏感信息）：
git push --force-with-lease origin main；--force绝对禁止在团队共享分支上使用
如何判断本地和远程到底差了多少
别猜，用命令看真实状态：
-
git status -sb：显示当前分支名、是否 ahead/behind 几个 commit，比如## main...origin/main [ahead 2, behind 1] -
git log --oneline --all --graph：可视化查看本地与远程分支的分叉关系 -
git fetch origin后再git log HEAD..origin/main：列出远程有、你本地没有的提交
注意：git pull 默认只拉取当前分支对应远程分支（如 main → origin/main），不会同步其他远程分支，除非显式指定。
首次推送或重命名默认分支时的坑
GitHub/GitLab 现在默认主分支名是 main，不是 master。如果你初始化本地仓库后直接 git push -u origin master，大概率失败。
- 先确认远程仓库实际默认分支名：访问仓库页面，看顶部显示的是
main还是master - 推送时严格匹配：
git push -u origin main（不是master） - 如果本地分支名是
master但远程是main，可重命名本地分支：git branch -M main，再推送
真正容易被忽略的点是：Git 从不自动同步分支名映射。你必须自己确保本地分支名、远程分支名、git push 命令中写的分支名三者一致，否则要么推错地方，要么被拒绝。
