请求解析Azure DevOps Repos提交过滤器类型：用途与工作原理

Simple history (Default) #

• 定义：默认的提交历史视图，将分支历史简化为线性流，自动隐藏合并分支的详细提交轨迹，只保留当前分支的核心提交链和合并节点。
• 开发者作用：日常开发中快速回顾当前分支的开发进度，不用被分支合并的复杂拓扑干扰，聚焦核心变更脉络，适合快速查阅提交记录。
• 实际工作机制：遍历当前分支的提交链，遇到合并提交时，仅保留指向当前分支的父提交路径，忽略合并进来的其他分支的完整历史，只展示合并节点本身，把交叉的分支历史“拉直”成线性。
• 合并类型关联：不依赖特定合并类型，对普通合并、squash合并、变基合并等所有合并方式都生效，核心逻辑是简化分支间的交叉历史。

First parent #

• 定义：严格追踪分支的第一个父提交路径，完全过滤掉所有合并进来的其他分支的提交，只展示当前分支从创建以来的原始线性主路径。
• 开发者作用：需要聚焦当前分支的核心演进逻辑时使用，比如排查仅主分支存在的问题，或者梳理分支的原始开发轨迹，彻底排除其他分支的干扰。
• 实际工作机制：每次回溯提交时仅沿着第一个父节点前进（Git中普通合并的第一个父是当前分支，第二个是被合并的分支），所有来自其他分支的提交都会被隐藏，仅显示当前分支自身的提交和合并节点，但合并节点关联的子分支历史不会展示。
• 合并类型关联：依赖Git的父提交顺序逻辑，对普通合并效果最明显；squash合并因为不会保留多父节点，所以在该场景下和Simple history效果接近。

Full History #

• 定义：展示所有关联的提交历史，包括当前分支、所有合并进来的分支的完整提交链，不做任何简化，呈现最原始的提交拓扑结构。
• 开发者作用：排查跨分支的问题根源（比如某个bug来自其他分支的合并）、进行代码审计或追溯完整变更轨迹时使用，能看到所有分支分叉、合并的细节。
• 实际工作机制：遍历所有可达的提交节点，包括当前分支的提交、所有合并分支的提交，完整展示分支的所有分叉与合并节点，相当于执行Git命令 git log --no-simplify-by-decoration 的效果。
• 合并类型关联：不依赖合并类型，无论采用哪种合并方式，都会还原最真实的提交图谱，展示所有相关提交。

Full History (simplify merges) #

• 定义：在完整展示历史的基础上，自动隐藏已完全合并到当前分支的分支提交，仅保留有意义的合并节点和未合并的分支历史。
• 开发者作用：既想掌握整体分支脉络，又不想被已完成合并的分支的冗余提交干扰，适合版本发布前梳理已合并/未合并分支状态，或分支清理前的检查。
• 实际工作机制：遍历所有可达提交，判断分支提交是否已全部合并到当前分支：如果是，则隐藏该分支的具体提交，仅保留合并节点；如果分支存在未合并提交，则完整展示该分支的历史，相当于执行Git命令 git log --simplify-merges 的效果。
• 合并类型关联：依赖合并完整性判断，仅当分支所有提交都合并到当前分支时才会简化；对普通合并、变基合并生效，而squash合并因为将分支提交压缩为单个提交，会直接显示该压缩提交，不会保留原分支历史。

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