Git: 关于GitLab提交网络图中master分支合并到自身的疑问

术语提前纠正 #

首先修正你描述中的不规范技术表述：

• 不存在「master分支从自身分叉」的概念，网络图的不同线路是提交祖先链的可视化呈现，master本质是指向最新提交的可变指针，不是固定的线路
• 你提到的「右侧master分支」实际是上游linux-stable原生提交链，左侧线路是GitLab镜像节点的操作提交链

问题1：表述准确性判断 #

你的表述不准确。
两条线路并不属于同一个master分支的左右两侧：右侧是上游linux-stable仓库维护者推送的原生提交链，左侧是GitLab镜像同步脚本的操作提交链，二者是两个独立的提交祖先链，仅在合并节点处产生关联。

问题2：空分叉线路的相关说明 #

这不属于常规的功能开发分支，该场景的专业术语是 非快进合并产生的空祖先链。
出现的原因是镜像同步脚本拉取上游提交时，强制使用了--no-ff（非快进）合并参数：

1. 镜像节点的本地master指针在箭头1对应的提交处，且本地无任何新提交
2. 上游master已经产生了多个新提交，本来可以直接快进移动本地master指针完成同步
3. 同步规则强制要求必须生成合并提交，不能直接快进，Git就会自动生成一条没有任何新提交的分叉线路，最终在箭头2处生成合并提交完成同步。
   这是Git的标准操作产物，属于完全正常的情况。

问题3：合并操作的意义与术语 #

该操作的专业术语是 非快进合并（No Fast-forward Merge），在此场景下的意义是明确标记镜像同步的操作节点，和上游原生提交做区隔，方便后续溯源。
常见使用场景包括：

• 仓库镜像同步场景：强制生成合并提交，可快速区分上游原生提交和镜像侧操作提交
• 团队协作场景：功能分支合并到主分支时强制非快进合并，后续需要回滚整个功能时，直接回滚合并提交即可，不需要逐个识别功能的多个提交
• 版本发布场景：发布分支合并到主分支时强制生成合并提交，作为版本发布的标记节点，方便后续版本回溯。

问题4：提交空缺的底层逻辑 #

你看到的「空缺」仅为GitLab网络图的UI渲染优化，和Git底层逻辑无关：
当某一条提交链在一段时间内无新提交、另一条关联提交链有连续多个提交时，GitLab为了避免两条链的节点错位重叠，会在无提交的链上用空白占位对齐有提交的链的节点，让拓扑结构更易读。
Git底层的提交链是完全连续的，箭头1指向的提交直接是后续合并提交的第一父节点，不存在任何提交断层。

内容的提问来源于stack exchange，提问作者NdFeB