Desktop项目中的Git可达与不可达提交解析-优快云博客

本文链接：https://blog.youkuaiyun.com/gitblog_00174/article/details/148362647

Desktop项目中的Git可达与不可达提交解析

desktop Focus on what matters instead of fighting with Git. 项目地址: https://gitcode.com/gh_mirrors/de/desktop

前言

在版本控制系统中，理解提交之间的关联关系对于高效管理代码历史至关重要。本文将深入探讨Git中的可达提交(Reachable Commits)与不可达提交(Unreachable Commits)概念，以及这些概念在Desktop项目中的实际应用。

Git提交图基础

Git采用有向无环图(DAG)来记录代码提交历史。每个提交(除了初始提交)都至少有一个父提交，这种结构形成了代码演进的完整路径。

基础示例

假设我们有一个主分支main，包含三个连续提交：

初始提交A
第二次提交B
第三次提交C

用图形表示如下：

gitGraph
   commit id: "A"
   commit id: "B"
   commit id: "C"

在这个简单案例中，所有提交都是相互可达的。我们可以从C回溯到A，因此A对C来说是可达的。

不可达提交的产生

当项目存在多个分支时，就会出现更复杂的情况。考虑以下场景：

从提交C创建新分支feature-branch
在新分支上做两次提交D和E
切换回主分支main并做提交F

此时提交图变为：

gitGraph
   commit id: "A"
   commit id: "B"
   commit id: "C"
   branch feature-branch
   checkout feature-branch
   commit id: "D"
   commit id: "E"
   checkout main
   commit id: "F"

可达性分析

从F出发：可以到达C、B、A
从E出发：可以到达D、C、B、A
关键点：无法从F到达E或D

这种分支分叉导致部分提交在主分支视角下成为不可达提交。

Git命令与可达性

许多Git命令依赖提交的可达性进行计算，最典型的是git diff命令：

git diff A..C：显示B和C的变更
git diff B..F：显示C和F的变更，但不包含D和E的变更

理解这一点对于准确解读差异结果至关重要。

合并提交的特殊性

当我们将feature-branch合并回main分支时，会产生一个特殊的合并提交G：

gitGraph
   commit id: "A"
   commit id: "B"
   commit id: "C"
   branch feature-branch
   checkout feature-branch
   commit id: "D"
   commit id: "E"
   checkout main
   commit id: "F"
   merge feature-branch tag: "G"

合并提交G有两个父提交：