HEAD指执行git merge时所在的当前分支，而非固定指master；例如在main分支运行git merge feature，则冲突标记中HEAD代表main分支内容，feature代表待合并分支内容。

冲突标记里HEAD到底指哪个分支

它指的不是“主分支”或“master”，而是你执行git merge时所在的那个当前分支——也就是HEAD此刻实际指向的分支。比如你在main上运行git merge feature，那冲突块里的就是<code>main分支的修改内容。

Conventional Git

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

下载

为什么HEAD不总是main或master

因为HEAD是动态的，完全取决于你当前在哪：

• 用git checkout dev切过去，HEAD就指向dev
• 用git switch release/v2切换后，HEAD就指向release/v2
• 甚至在分离头状态（git checkout abc123）下，HEAD直接指向提交哈希，此时git merge会报错，根本不会产生冲突标记

所以看到冲突里的HEAD，第一反应应该是查git branch输出的*号位置，或者直接跑git rev-parse --abbrev-ref HEAD确认。

HEAD和merge_head在冲突中分工明确

Git内部用两个指针区分来源：

• HEAD：当前分支的最后一次提交内容（即你正在工作的分支）
• MERGE_HEAD：待合并分支的最新提交（Git自动写入.git/MERGE_HEAD，对应冲突标记里的>>>>> feature部分）

它们不是对称关系——HEAD是“基线”，MERGE_HEAD是“变更源”。如果你误把HEAD当成“更权威”的一方去保留，而没意识到它只是当前分支，就可能丢掉本该保留的逻辑。

容易被忽略的边界情况

真正容易出错的不是常规合并，而是这些场景：

• 在rebase过程中遇到冲突，其实是rebase目标分支（如<code>main）的内容，而不是你原分支的旧版本
• 执行git cherry-pick时，HEAD指向当前分支，但冲突内容来自被挑拣的提交，此时HEAD仍代表“接收方”，不是“来源”
• 多人协作中，有人在HEAD指向staging时合并hotfix，结果冲突里HEAD是staging而非main，但团队文档却默认写“HEAD = main”

别依赖记忆或命名猜测，每次遇到冲突，先敲git rev-parse --abbrev-ref HEAD——这行命令比看分支名更可靠。