vs code中解决git拉取冲突需先识别冲突标记：> feature-x为待合并分支修改；点击“accept current change”或“accept incoming change”按钮选择保留版本，手动合并时须删除全部三行标记，保存后立即执行git add 标记已解决，否则提交按钮将灰显。
VS Code 中点几下就能解决冲突，但得先看懂标记
VS Code 内置的 Git 支持能直接识别 、<code>=======、>>>>>> feature-x 这类冲突标记，并在编辑器右侧给出操作按钮。但前提是：你得知道哪边是当前分支（HEAD）、哪边是待合并分支（feature-x），否则容易点错。
常见错误现象：
- 点了
Accept Incoming Change却发现删掉了自己刚写的逻辑 - 保存后没运行
git add，VS Code 状态栏仍显示“Conflicted”，提交按钮灰掉
实操建议：
- 打开冲突文件后，先快速扫一眼两段代码的业务含义，别光看按钮文字
- 如果两段都得留，手动合并后务必删掉三行冲突标记，否则
git add会报错 - 改完一个文件就立刻
git add <file></file>，别等全改完再统一加——避免中途误操作导致状态混乱
IntelliJ IDEA / WebStorm 的 Resolve Conflicts 对话框怎么选
IDEA 点击冲突文件右键 → Git → Resolve Conflicts 会弹出图形化对比窗口，左侧是当前分支（LOCAL），右侧是传入分支（REMOTE），中间是合并结果预览区。
使用场景：
- 冲突跨多处、涉及函数重命名或结构变动时，比纯文本编辑更安全
- 团队约定用某一方代码为主干，可直接点击
Use Left或Use Right批量覆盖
容易踩的坑：
Lovefromio Github
下载
使用 `gh` CLI 与 GitHub 交互。通过`gh issue`、`gh pr`、`gh run` 和 `gh api` 管理 issue、PR、CI 运行以及高级查询。
-
Use Left是保留你当前分支的代码，不是“左边那个”——名称容易误导，尤其对新用户 - 如果中间预览区出现红色波浪线（语法错误），说明手动合并有遗漏，不能直接点
Apply - 对话框关闭后不会自动
git add，必须手动执行或勾选 “Add to VCS after resolve”
Sublime Text / Vim / 记事本这类纯文本编辑器怎么不翻车
没有图形界面辅助时，靠的是对冲突标记格式的肌肉记忆和终端命令的配合。关键不是“能不能改”，而是“改完怎么让 Git 认出来”。
参数差异与风险点：
和 <code>>>>>>> branch-name必须成对删除，漏删任意一行都会导致git commit失败并报错：fatal: cannot do a partial commit during a merge- 用
git diff --ours和git diff --theirs可分别查看 LOCAL / REMOTE 版本，比来回切分支快得多 - 如果冲突文件太多，别手敲
git add每个文件名，用git add -u（只加已跟踪文件的修改）更稳妥
为什么 git rebase 冲突后不能 git commit
这是最常被忽略的兼容性细节：rebase 过程中遇到冲突，git commit 会创建新提交，破坏 rebase 的线性历史，后续 git rebase --continue 会失败或跳过预期提交。
正确流程只有两条路：
- 解决完所有冲突文件 →
git add .→git rebase --continue - 想放弃当前 rebase →
git rebase --abort（注意：这会丢弃所有未提交的解决动作）
性能影响：rebase 冲突解决过程无法并行，每次 --continue 都要重放一次提交，分支越长越耗时；而 merge 冲突只需一次提交，适合协作频繁的主干分支。
