git push 本身不产生冲突，报 conflict 是因上一次 git pull 或 merge 留下未解决的冲突文件，导致 Git 拒绝后续操作；需先用 git status 查看 Unmerged 文件，手动解决冲突、git add、git commit 后才能 push。
git push 报 conflict 时，其实根本没到推送那步
Git 的 git push 本身不会触发合并冲突——它只负责把本地提交推到远程。你看到的“推送冲突”，99% 是因为上一次 git pull 或 git merge 卡在了未解决的冲突状态，而你忘了处理就直接 git push。此时 Git 拒绝推送，报错类似：
fatal: Exiting because of an unresolved conflict.
这不是远程拒绝，是本地 Git 主动中止：它发现工作区还有未标记解决的冲突文件，连 git commit 都不允许，更别说 push。
所以第一步永远是确认当前状态：
-
git status—— 看哪些文件标着Unmerged paths -
git log --oneline --graph --all—— 快速确认是否真在 merge 中途（HEAD 会显示(HEAD detached at ...)或带merge提交信息）
冲突文件里出现
这是 Git 插入的三路合并标记，不是错误，而是明确提示：“这里我没法自动选，你来定”。三段内容分别对应：
-
<<<<<< HEAD到=======：你当前分支（比如main）的修改 -
=======到>>>>>> feature/login：你要合并进来的那个分支（比如feature/login）的修改 - 中间没有逻辑约束——你可以全删、全留、混写，甚至重写一行新代码
常见误操作：只删了 <<<<<< 和 >>>>>>，却漏掉 =======，导致语法错误；或保留了两段代码但没删标记，Git 仍认为冲突未解决。
Conventional Git
下载
Conventional Commits v1.0.0 分支、工作树命名及提交信息规范，适用于 GitHub 与 GitLab 项目，用于创建分支和命名工作树等场景。
用 git mergetool 能跳过手动编辑吗
可以，但不推荐无脑用。运行 git mergetool 会调起图形化工具（如 meld、vimdiff），把 base / local / remote 三份内容并排展示，帮你对比选择。但它有硬限制：
- 必须提前配置好工具：
git config --global merge.tool meld（或vimdiff） - 对“一方删文件、另一方改文件”这类冲突，图形工具可能只显示空 vs 修改，容易误判保留空文件
- 如果冲突涉及大量行（比如整个函数重写），工具界面反而比直接看文本更难定位差异点
真正省时间的场景是：冲突分散在多个文件，且每处都只是几行微调——这时 git mergetool -y 可批量过一遍。
解决后 git add . 为什么还报 conflict
最常被忽略的一点：Git 要求你对**每个冲突文件单独执行 git add**，而不是靠 git add . 偷懒。原因在于：
-
git add .只会暂存“已修改且未冲突”的文件 - 冲突文件处于“unmerged”状态，Git 认为它们仍需人工确认，必须显式
git add <file>才算标记“我审过了” - 漏掉任意一个文件，后续
git commit就会失败，并再次抛出fatal: Exiting because of an unresolved conflict.
验证方法：执行完所有 git add 后，再跑一次 git status —— 如果输出里不再出现 Unmerged paths，只有 Changes to be committed，才算真正干净。
