在gitmerge/rebase中，如何不因git而责怪作者

Question

问题：

• tasks/pbi的所有更改似乎都属于PR所有者，因此git指责显示我们的发布经理拥有代码的80%
• 无法找到谁更改了代码以及更改原因

TL；DR：我们有一个主分支，从中创建了一个pbi(功能(分支，每个作者都有自己的pbi任务分支。将南瓜合并到pbi(PR(中，并将pbi合并到master(PR(。

我们的开发流程如下：

工作流

PBI生命周期

1. PBI是任务的容器

2. 创建具有相关说明和验收条件的PBI。

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

4. 在工作进行期间，所有者有责任将PBI的分支与master合并
5. PBI的所有任务完成后(请参阅下面的任务工作流(，创建一个到master的拉取请求(合并(，分配代码/产品审查和QA，并移动到已解决状态
6. 解析后更改：
   1. 在PBI中创建一个新任务，以便于进行所需的修复/更改
7. 在审查和QA之后，批准拉取请求并合并到master。这将关闭PBI并将其移动到Done状态

任务生命周期

1. 任务是最小的工作项，由单个开发人员执行
2. 创建一个具有相关描述和验收条件的任务
3. 任务在待办事项状态下开始其生命
4. 开始处理任务时：
   1. 创建一个以父PBI的分支作为目标分支的分支，并使用命名约定tasks/123-my-task-name
5. 尽可能频繁地提交和推送代码。在Azure DevOps中就任务的工作项展开讨论
6. 任务所有者有责任在需要时将任务的分支重新设置在其父PBI分支之上
7. 工作完成后：
   1. 创建一个返回PBI分支的pull请求，并指定一个所有者进行代码审查
8. 代码审查完成后，审查人员批准更改，并将其合并(rebase-push(回PBI的分支。这将关闭任务并将其移动到Done状态

竣工要求

1. 所有组件级测试(例如单元测试(都必须通过
2. 必须遵守规范审查

Answer 1

您正在进行挤压合并。压缩合并提交只能引用一个作者。压缩合并提交是由GitLab在通过GitLab UI进行合并时创建的。这将使用当前用户会话中的作者信息，该会话似乎是您流程中的发布管理器。

要保留每行的原始作者，请不要创建挤压提交。相反，使用real合并并保留单个提交的历史记录(每个提交都有单独的作者信息(。