git用head标识当前分支（“我们这边”），用合并分支名标识被合并方（“他们那边”）；冲突块中> branch-name之间为分界，需删除三行标记并保留正确逻辑代码，解决后必须git add。

Git冲突时怎么知道哪边是当前分支、哪边是合并进来的代码

Git默认用HEAD标记你当前检出的分支（也就是“我们这边”），用merge_commit_hash（或分支名，取决于你用的是git merge还是git pull）标记要合并进来的那一方（也就是“他们那边”）。你在冲突块里看到的和<code>>>>>>> branch-name之间就是分界线——别靠猜，就认这两行标识。

常见错误是以为HEAD是“旧代码”，其实它只是“你现在站在哪个提交上”。如果你在feature分支上执行git merge main，那HEAD就是feature的最新提交，main才是被合并进来的一方。

手动编辑冲突文件时该删哪部分、留哪部分

保留逻辑正确的代码，不是“留左边”或“留右边”。冲突块结构固定，删掉整段分隔符及无用标记：

• 必须删除、<code>=======、>>>>>> branch-name这三行
• 只保留你确认要的代码：可以全留HEAD部分，也可以全留另一方，也可以手工拼接（比如把HEAD里的变量声明 + 另一方的函数调用）
• 删完后务必检查语法（尤其JS/Python这类对缩进或分号敏感的语言），IDE通常会高亮残留标记，但终端里不会提醒

示例（Python）：

>>>>> main

若你确定要平方逻辑，删掉三行标记后只留第二段函数定义即可。

Cnb Cool Git

CNB 云原生构建平台的 Git 操作技能，支持代码克隆、提交、推送、分支管理、Merge Request 管理、流水线触发与结果读取。初次使用需收集用户的 Git 用户名和邮箱。

下载

用git checkout快速取舍（不手改）

适合明确只想用某一方全部代码的场景，省得逐个文件删标记。注意这不是“回退”，而是覆盖工作区内容：

• 只保留当前分支（HEAD）的版本：git checkout --ours path/to/file.py
• 只保留合并来源分支的版本：git checkout --theirs path/to/file.py
• 这两个命令只影响指定文件，不影响暂存区状态，执行后仍需git add标记为已解决
• 如果合并的是多个提交（比如git merge feature-A feature-B），--theirs可能指向最后一个被合并的分支，行为不如单次合并明确

为什么git mergetool有时反而更慢

图形化工具（如vimdiff、vscode、meld）能高亮差异、提供按钮操作，但启动开销大，且默认配置常把冲突块拆成“本地/远程/基础”三栏——实际项目中“基础”版本往往早过时，参考价值低。容易卡在纠结“要不要用中间栏”上。

真正提效的方式是：

• 先用git diff --name-only --diff-filter=U快速列出所有冲突文件，心里有数
• 对简单文件（JSON、配置、单函数）直接手改；对复杂逻辑文件再开mergetool
• 避免在mergetool里反复切窗口，改完立刻保存退出，别留着多个临时文件开着

最常被忽略的点：冲突解决后忘记git add。Git不自动标记“已解决”，没add就无法commit，错误信息fatal: cannot do a partial commit during a merge就是在提醒这个。