git merge时无法跳过冲突，但可用git checkout --ours 保留当前分支代码或git checkout --theirs 采用待合并分支代码，执行后需git add 并git commit完成解决。

git merge 时怎么跳过冲突、直接用某边代码

Git 不提供“自动选 HEAD 或自动选 feature”的开关，但有明确命令能绕过冲突标记、强制采用某一方的变更。关键不是“跳过”，而是“告诉 Git：我不要三路合并，就照这个版本来”。

• git checkout --ours <file></file>：保留当前分支（HEAD 所在分支）的全部内容，丢弃待合并分支的修改
• git checkout --theirs <file></file>：采用待合并分支的全部内容，丢弃当前分支的修改
• 这两个命令只作用于已发生冲突的文件，且必须在 git merge 中断后、git add 前执行
• 执行后需 git add <file></file> 标记为已解决，再 git commit

为什么不能直接用 git checkout -b 重拉一个分支

有人想“干脆切个新分支，把目标分支代码全拷过去”，这看似绕开冲突，实则破坏了 Git 的历史追踪和协作语义。你丢失了：原分支的提交哈希、作者信息、时间戳、以及与共同祖先的 diff 关系。后续 git log --oneline --graph 会断掉，git blame 查不到真实修改人。

• 真正需要“全量覆盖”时，应先 git merge --abort 中止当前合并
• 再用 git reset --hard origin/<target-branch></target-branch> 强制重置当前分支到远程目标分支状态（慎用，本地未推送提交会丢失）
• 或用 git restore --source=origin/<target-branch> --staged --worktree <file></file></target-branch> 单文件覆盖（Git 2.23+）

git checkout --ours/--theirs 在 rebase 场景下行为不同

同一个命令，在 git merge 和 git rebase 中含义相反 —— 这是容易踩坑的点。rebase 时：--ours 指的是“rebase 目标分支”（即你要变基到的那个分支），--theirs 指的是“正在被变基的当前分支”。

Conventional Git

Conventional Commits v1.0.0 分支、工作树命名及提交信息规范，适用于 GitHub 与 GitLab 项目，用于创建分支和命名工作树等场景。

下载

• 所以别死记“ours = 当前分支”，要结合上下文看 HEAD 指向谁、操作类型是什么
• 不确定时，先 git status 看提示，或运行 git rev-parse --abbrev-ref HEAD 确认当前分支名
• 更安全的做法是：用 git show :1:<file></file>（merge-base）、:2:<file></file>（HEAD）、:3:<file></file>（MERGE_HEAD）分别检出三方内容做比对

合并前预防比强行覆盖更值得投入精力

强制采用某边代码本质是放弃协商，适用于配置文件、锁文件、或明确知道某方修改已废弃的场景。但多数业务代码冲突，真正的问题不在“怎么快”，而在“为什么两个人改同一行”。

• 提前约定文件归属（如 API 接口定义由后端维护、样式由前端维护）
• 用 git pull --rebase 替代 git pull，减少无意义的合并提交和分叉
• 功能分支生命周期不宜过长，频繁同步主干可降低冲突概率

最常被忽略的一点：--ours 和 --theirs 只对当前文件生效，不递归处理子模块或未跟踪文件；如果项目里混用了 .gitmodules 或生成代码，得单独处理。