问题：

• 所有来自task / pbi的更改似乎都属于PR所有者，因此git blame显示我们的发布经理对代码拥有80％的所有权。
• 不可能找到更改代码的人以及原因

TL; DR：我们有一个master分支，从中创建了一个pbi（feature）分支，每个作者都从pbi中拥有自己的任务分支。将壁球合并到pbi（PR），然后将pbi合并到master（PR）。

我们的开发流程如下：

工作流程

1. PBI是任务的容器。

2. 创建具有相关描述和接受条件的PBI。

3. 开始为PBI进行实际工作时，创建一个以master作为目标分支并命名约定features/123-my-feature-name的分支。

4. 正在进行工作时，所有者有责任将PBI的分支机构与master合并。
5. 完成PBI的所有任务后（请参见下面的任务工作流程），向master创建拉取请求（合并），分配代码/产品评论和质量检查，然后移至已解决状态。
6. 分辨率后的变化：
   1. 在PBI内创建一个新任务，以方便进行所需的修复/更改。
7. 经过审查和质量检查后，批准提取请求并合并到master。这将关闭PBI并将其移至 Done 状态。

1. 任务是由单个开发人员执行的最小的工作项。
2. 创建具有相关描述和接受条件的任务。
3. 任务以“
4. 开始执行任务时：
   1. 使用父PBI的分支作为目标分支并命名约定tasks/123-my-task-name创建一个分支。
5. 尽可能频繁地提交和推送代码。在Azure DevOps中对该任务的工作项进行讨论。
6. 任务所有者有责任在需要时在其父PBI分支的顶部变基该分支。
7. 工作完成后：
   1. 创建一个向PBI分支返回请求的请求，并指定所有者进行代码审查。
8. 代码审查完成后，审查者批准更改，并将其合并（重新压实）回到PBI的分支机构。这将关闭任务并将其移至 Done 状态。

1. 所有组件级测试（例如单元测试）必须通过
2. 代码审查必须遵守