在基于Git的现代软件开发流程中，Pull Request（PR）是代码审查与协作的核心环节。使用Azure DevOps的团队经常会遇到一个看似简单却容易混淆的问题：当创建一个Pull Request时，分支上的父提交（parent commit）是否会被一起发送到目标分支？这个问题直接关系到代码合并的完整性、审查效率以及分支管理策略。本文将从Git原理出发，结合Azure DevOps的实际机制，为您详细解答这一困惑。

Git提交与父提交的基本概念

要理解父提交在PR中的行为，首先需要明确Git提交的结构。每个Git提交对象都包含一个指向其父提交的指针。对于一个普通的单亲提交，它只有一个父提交；而对于合并提交（merge commit），则有两个或更多父提交。当你从主分支（如main）创建特性分支并在此分支上工作，特性分支上的第一个提交的父提交就是主分支的某个历史提交。这个“基础提交”就是通常所说的父提交。

在Pull Request的上下文中，我们关注的父提交通常是指目标分支（如main）上的最新提交，即源分支（feature分支）从目标分支分叉的那个点。例如，你在main分支的commit A处创建了feature分支，然后提交了B和C。那么对于feature分支上的B和C而言，A就是它们的父提交（或者更准确地说，B的父提交是A，C的父提交是B）。

Azure DevOps Pull Request的提交包含机制

当你在Azure DevOps中创建一个Pull Request，例如将feature分支合并到main分支，系统会计算两个分支的差异（diff）。具体来说，Azure DevOps会找出feature分支上所有不在main分支中的提交，并将这些提交的差异作为PR的内容。这包括feature分支上新增的所有提交（B、C等），但不包括已经存在于main分支上的提交（例如A）。换句话说，父提交A作为目标分支的一部分，并不会被“发送”到PR中；PR所包含的仅仅是源分支独有的提交。

那么，父提交是否会在PR的提交历史中显示？答案是：不会直接作为PR的一部分。但在Azure DevOps的PR详情页中，有一个“Commits”选项卡，它会列出源分支上所有尚未合并到目标分支的提交。这些提交都会显示其完整的提交信息，包括它们的父提交哈希值。因此，你可以看到每个提交的父提交是谁，但父提交本身并不会出现在PR的提交列表中，因为它已经在目标分支上了。

特殊情况：合并提交与父提交

当你的特性分支包含合并提交时，情况会变得稍微复杂。例如，如果feature分支定期从main分支拉取最新代码（执行git merge main），就会产生一个合并提交，该合并提交有两个父提交：一个是feature分支原来的最新提交，另一个是main分支上的最新提交。在Azure DevOps PR中，这个合并提交会被视为feature分支上的一个普通提交，并会包含在PR的差异中。此时，合并提交的两个父提交都会被记录，但只有其中一个父提交（即main分支上的那个）可能已经存在于目标分支中。Azure DevOps在处理这种场景时，会智能地识别重复的提交内容，避免冲突。因此，虽然合并提交本身会出现在PR中，但它的父提交（尤其是目标分支上的那个）并不会被重复“发送”，因为目标分支已经拥有该提交。

对代码审查与合并策略的实际影响

理解父提交在PR中的行为有助于开发团队制定更合理的合并策略。例如：

  1. 避免冗余审查：如果团队习惯在特性分支上频繁合并main，会造成PR中包含大量合并提交，这些合并提交的diff通常只有很小的冲突解决内容，却会干扰代码审查的焦点。最佳做法是尽量使用变基（rebase）而非合并，保持提交历史的线性，这样每个PR只包含真正的功能变更。

  2. 父提交的可见性：虽然父提交不出现在PR中，但审查者可以通过“Commits”选项卡查看每个提交的上下文。如果某个提交的父提交信息不明确，可能会增加审查难度。因此，团队应鼓励编写清晰的提交信息，并在PR描述中说明分支的分叉点。

  3. 合并冲突处理：当PR存在冲突时，Azure DevOps会提示需要解决冲突。解决冲突的过程本质上是创建一个新的合并提交，该提交的父提交包括源分支最新提交和目标分支最新提交。这个新生成的合并提交会被添加到PR中，但原有父提交（如冲突前的状态）依然保留在各自分支上。

最佳实践：如何避免混淆

为了确保Pull Request的清晰性和可管理性，建议遵循以下实践：

  • 使用变基而不是合并：在推送PR之前，将特性分支变基到目标分支的最新版本，确保PR只包含你的新提交，没有多余的合并提交。这样父提交就是目标分支的当前头，一目了然。

  • 控制PR的大小：每个PR应专注于一个功能或修复，提交数量不宜过多。过长的提交链会使父提交关系复杂化，增加审查负担。

  • 利用Azure DevOps的“政策”：在分支策略中启用“强制线性历史”或“检查提交消息规范”，可以自动约束团队行为，减少因父提交混乱导致的问题。

结论

回到最初的问题：父提交是否会随Pull Request一起发送？答案是否定的。在使用Azure DevOps时，Pull Request只包含源分支上相对于目标分支的新增提交，而父提交（即目标分支上已有的提交）不会被重复发送。但是，父提交的信息会作为提交元数据被记录，并通过PR的提交选项卡可见。理解这一机制有助于开发者正确使用分支合并策略，提升代码审查效率，并避免不必要的冲突与混乱。在DevOps实践中，清晰掌握工具的行为细节，往往能让团队的协作流程事半功倍。