git merge冲突时需手动编辑文件保留双方修改，删去冲突标记后git add并commit；rebase同理，禁用--skip以防丢失修改；--ours/--theirs会丢弃一方代码，应改用git show导出对比后手工合并。
git merge 冲突时怎么保留双方修改
默认 git merge 遇到冲突会停在「未合并状态」，只保留冲突标记（<<<< HEAD / ====== / >>>> branch-name），不自动丢弃任何一方——但你得手动编辑文件，把两段都留进去，再 git add 标记为已解决。
关键不是“Git 能不能保留”，而是“你有没有显式写进文件里”。很多人以为 Git 会智能合并逻辑，其实它只做行级/块级文本比对，语义合并靠人。
- 打开冲突文件，找到形如
<<<< HEAD的三段式标记 - 把
<<<< HEAD和======之间的当前分支修改，和======到>>>> branch-name之间的目标分支修改，全部保留并手动整合（比如顺序调换、加条件判断、拆成两个函数） - 删掉三行冲突标记本身（
<<<<、======、>>>>） -
git add <file>，再git commit完成合并
rebase 过程中想同时保留 A 分支和 B 分支的改动
git rebase 本质是「重放提交」，冲突处理逻辑和 merge 一样：它不会覆盖或删除任何代码，但你需要在每个冲突提交点手动编辑、保存、git add、git rebase --continue。
容易踩的坑是：用 git rebase --skip 跳过冲突提交，这会导致那个提交的修改彻底丢失，且不可逆（除非你提前备份了 reflog）。
- 遇到冲突时，先
git status看哪些文件 Unmerged - 编辑文件，把两个分支的逻辑都保留下来（例如：原函数保留，新函数另起名字；或用
if (process.env.NODE_ENV === 'dev')区分路径） - 确认无误后
git add <file>，再git rebase --continue - 不确定时，用
git rebase --abort回退，比硬着头皮 skip 安全得多
用 git checkout --ours / --theirs 解决冲突但又不丢代码
git checkout --ours 和 git checkout --theirs 是快速覆盖命令，**它们会直接丢弃另一方的修改**——这不是“保留双方”，而是“选一边”。如果真想两边都要，别用这两个命令。
抓取指定 GitHub用户的 Stars 项目，生成标准化中文 Markdown 报告。用户提及「分析 GitHub stars」「导出收藏项目」「汇总 GitHub 星标」「生成 stars 报告」或粘贴含 ?tab=stars 的链接时触发。执行通过 bash...
但可以借它的思路做安全操作：先用 git show HEAD:<file> 和 git show MERGE_HEAD:<file> 分别导出双方原始版本，存为临时文件对比，再手工合并到工作区。
git show HEAD:src/utils.js > utils-ours.jsgit show MERGE_HEAD:src/utils.js > utils-theirs.js- 用 VS Code 或 vim -d 对比两个文件，复制需要的部分到当前冲突文件中
- 完成后删掉临时文件，
git add src/utils.js
复杂逻辑冲突建议用 IDE 的合并工具而非纯命令行
VS Code、IntelliJ、JetBrains 系列都内置三路合并视图（Base / Current / Incoming），能高亮差异块、支持逐块 Accept Current / Accept Incoming / Accept Both，比手动删标记可靠得多。
命令行下没有“Accept Both”按钮，但你可以用 git merge-file 做底层合并（需提供 base 版本），不过多数人没必要碰——IDE 已经封装好了等价能力。
- 在 VS Code 中打开冲突文件，点击右上角「Accept Current Change」旁的下拉箭头 → 选「Accept Both Changes」
- 注意：这个操作仅合并当前冲突块，不是整文件；多个冲突块要分别处理
- 合并完仍需
git add，否则 Git 不认为冲突已解决
最常被忽略的一点：保留双方修改 ≠ 代码能直接运行。函数重名、变量重复声明、import 冲突、类型定义覆盖……这些语法/逻辑问题不会被 Git 检测，必须人工验证或跑一遍测试。别提交前只看 diff，要真跑起来。
