Git 拒绝提交是因检测到内容冲突而非代码错误；需手动编辑文件删除 标记，保留最终逻辑后执行 git add 更新暂存区，再 git commit。
能提交，但必须先解决冲突——Git 拒绝你提交，不是因为代码坏了，而是它在等你做决定。
git status 显示 both modified 就是冲突已发生
执行 git status 后，如果看到类似 both modified: src/LoginController.java 的提示，说明 Git 已检测到同一文件在两个分支中被修改，且无法自动合并。这不是网络或权限问题，纯粹是内容逻辑冲突。
- 此时
git commit会失败，报错信息里通常不含“error”字眼，而是提示 “no changes added to commit” 或 “you have unmerged paths” - 别用
git push -f强推——这会覆盖别人刚合入的修改，且无法回退 - 打开对应文件，你会看到三段标记：
（你当前分支的内容）、<code>=======（分隔线）、>>>>>> feature/login（要合并进来的分支内容） - 删掉这三行标记，只保留融合后的最终逻辑，保存文件
git add 后才能继续 commit
很多人删完标记就直接 git commit，结果还是失败。Git 不靠“文件是否保存”判断冲突是否解决，而是靠暂存区状态。
- 必须显式执行
git add src/LoginController.java（或git add .如果只有这一个冲突文件） - 再运行
git status，确认该文件状态变为modified: src/LoginController.java（不再是both modified） - 这时才能
git commit -m "resolve conflict in LoginController" - 如果误操作导致暂存了错误版本，可用
git restore --staged <file></file>撤回暂存
git pull 失败后怎么续
git pull origin main 报冲突，并不意味着拉取失败——git fetch 阶段已完成，只是 git merge 卡住了。你的本地 HEAD 仍指向 main，但工作区处于“半合并”状态。
- 不用重新
git pull，直接处理冲突文件即可 - 若想放弃这次合并、退回拉取前状态，用
git merge --abort（不是git reset） - 若本地有未提交修改又想先同步远程，推荐先
git stash，再git pull，最后git stash pop - 长期协作中，
git pull --rebase可避免生成无意义的 merge 提交，但要求你理解 rebase 后的提交 hash 会变
真正容易被忽略的是：冲突标记本身不是 bug，而是 Git 给你的决策界面。删掉
