冲突不是错误，而是Git要求你决定如何整合双方修改；遇到CONFLICT或Automatic merge failed时，先用git status定位冲突文件，再手动编辑删除<<<<<<<、=======、>>>>>>>标记并整合逻辑，最后git add和git commit完成解决。
冲突不是错误，是 Git 在告诉你：“这两处修改我没法替你选，得你来拍板。”
看到 CONFLICT (content) 或 Automatic merge failed 怎么办
这是 Git 明确提示你有文件内容冲突，常见于 git pull、git merge、git rebase 过程中。它不会破坏你的代码，只是把双方修改都保留在文件里，并用标记框出来。
- 先别慌着删标记或乱改——标记本身不参与运行，只是临时占位符
- 立刻执行
git status，它会列出所有both modified的文件，这才是你要盯住的清单 - 如果刚触发冲突就后悔了，
git merge --abort或git rebase --abort能干净回退到操作前状态，不残留任何暂存/修改
手动编辑冲突文件时的关键识别点
打开一个带冲突的文件，你会看到类似这样的三段式结构：
<<<<<< HEAD
public void save(User u) { /* 主分支逻辑 */ }
=======
public void save(User u) { /* feature 分支新逻辑 */ }
>>>>>> feature/save-user
注意：HEAD 指当前所在分支的版本，feature/save-user 是你正要合并进来的分支名（不是远程名，也不是提交哈希）。
Github Stars Analyzer
下载
抓取指定 GitHub用户的 Stars 项目，生成标准化中文 Markdown 报告。用户提及「分析 GitHub stars」「导出收藏项目」「汇总 GitHub 星标」「生成 stars 报告」或粘贴含 ?tab=stars 的链接时触发。执行通过 bash...
- 不要只看上下文，重点比对两段代码的语义差异：是参数变了？返回值类型不同？还是整个方法被重写了？
- 如果两段逻辑其实可以共存（比如新增了日志或校验），就手动合并，删掉三行标记，保留整合后的代码
- 若不确定哪段该留，先
git checkout --ours或git checkout --theirs临时切出单边版本验证行为，再决定最终取舍
用 git mergetool 加速解决多文件冲突
当冲突文件超过 2–3 个，或者单个文件冲突块密集时，命令行手动处理效率低且易漏。这时 git mergetool 就不是“可选”，而是“推荐”。
- 它依赖你提前配置的工具，比如
kdiff3、bcompare、vimdiff，配置方式是git config --global merge.tool kdiff3 - 运行
git mergetool后，它会逐个打开冲突文件，提供左侧（LOCAL）、右侧（REMOTE）、中间（BASE，即共同祖先）三栏对比，比纯文本标记直观得多 - 工具里点“Accept Merge”或保存退出后，Git 自动执行
git add标记该文件已解决，不用你再手动敲一遍 - 如果中途想跳过某个文件，按提示输入
q或直接关掉工具窗口即可，它不会中断整个流程
解决完不 git add 就 git commit 会怎样
Git 会拒绝提交，并报错 nothing to commit, working tree clean —— 因为冲突文件仍处于 unmerged 状态，未被 git add 收录进暂存区。
- 必须对每个已编辑完毕的冲突文件单独执行
git add <file>，或一次性git add .（但要注意别误加其他未审核的修改） -
git commit时 Git 会自动生成合并提交信息，如果你不想用默认的，加-m参数覆盖，比如git commit -m "merge: resolve UserService.java conflict" - 别忽略
git push这最后一步——解决冲突并提交只是本地动作，不推送到远程，别人拉取时照样会遇到同样冲突
真正容易被忽略的是：冲突解决不是“修好一个文件就完事”，而是“确认所有变更逻辑一致”。比如你保留了 A 分支的数据库字段名，却没同步 B 分支对应的 DAO 层映射，上线后可能直接报 SQLException。所以解决完别急着提交，至少在本地跑通相关单元测试或手动验证路径。
