问题：

• 任务/pbi中的所有更改似乎都属于PR所有者，因此git责备表明我们的发布经理拥有大约80%的代码。
• 无法找到谁修改了代码以及原因

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

我们的开发流程如下：

工作流

PBI生命周期
1.PBI是任务的容器。
1.创建具有相关描述和验收条件的PBI。
1.当PBI的实际工作开始时，创建一个以master为目标分支的分支，并命名约定features/123-my-feature-name。
1.当工作正在进行时，业主有责任将PBI的分支与master合并。
1.当PBI的所有任务都完成后（见下面的任务工作流），创建一个请求（合并）到master，分配代码/产品审查和QA，并移动到“已解决”状态。
1.决议后变更：
1.在PBI内创建一个新任务，以促进所需的修复/更改。
1.审查和QA后，批准拉取请求并合并到master。这将关闭PBI并将其移动到“完成”状态。
任务生命周期
1.任务是最小的工作项，由单个开发人员执行。
1.创建具有相关描述和验收条件的任务。
1.任务开始于“待办事项”状态。
1.开始执行任务时：
1.创建一个分支，将父PBI的分支作为目标分支，命名约定为tasks/123-my-task-name。
1.尽可能频繁地提交和推送代码。在Azure DevOps中讨论任务的工作项。
1.每当需要时，任务所有者有责任在父PBI分支的基础上重新设置任务分支的基础。
1.工作完成后：
1.创建一个拉回PBI分支的请求，并指定一个所有者进行代码审查。
1.代码评审完成后，评审员批准更改，并将其合并（重新基挤压）回PBI的分支。这将关闭任务并将其移动到“完成”状态。
竣工要求
1.所有组件级测试（如单元测试）必须通过
1.代码审查必须符合