导读：你的研发团队是否受到重复的 git 问题的困扰？本文有一定价值参考。

竞争过度，导致拥挤的拉取请求如何处理？一组研究人员发现了组织中开发团队可能正以各种方式以并不理想的效率工作着。

您的 GitHub 项目中是否有重复提交的问题？或者是否有相互竞争的拉取请求占用了团队的时间？

一组研究人员发现，组织的沟通风格或委派工作的方式可能是问题的一部分。

任何项目经理都知道，开发人员通过git 和 git 服务（例如GitHub和GitLab ）上的问题和拉取请求（PR）进行工作。

根据巴西帕拉联邦大学和不列颠哥伦比亚大学的一组研究人员披露，他们研究了这些编码行为，并将它们绘制在图表上，以便查看可以发现什么“隐藏的模式”。

在您自己团队的发展中寻找这些模式可能会发现可以优化工作流程的领域。

在今年早些时候的Linux 基金会开源峰会上发言的研究人员之一Emilie Ma指出：

“如果您的项目拥有过多的竞争 PR 或‘重复问题’，那么可能会被要求重新进行代码审查或错误报告实践，”

研究人员如何追踪 GitHub 行为？

该研究团队已经研究了 56 个 GitHub 项目，并记录了这些项目产生的所有问题和 PR。在图形模型（在Neo4j中捕获）中，问题和 PR 表示为节点，它们之间的链接表示为边。

在 Git 工作流中，创建问题是为了确定要完成的工作。生成的代码随后被打包到 PR 中，然后通常会在合并到核心代码主体之前对其进行审查。在理想情况下，单个 PR 即可解决问题。

就链接而言，问题可以是打开的（表示工作或讨论正在进行中），也可以是关闭的。PR 也是一样，只不过一旦完成，它们就会进入另一个状态，也就是合并。问题和 PR 都可以重复。作者和时间戳也被收集起来。

Emilie Ma说道： “这种基于图形的方法为一系列以前未描述过的协作软件工程实践提供了一个窗口。”

在此过程中，他们构建了一个可视化工具Workflows Explorer来显示结果。

先前的研究分别研究了问题和 PR，但同时研究它们还是有价值的。

Emilie Ma还说道：“在实践中，问题和 PR 是结合在一起的：问题经常通过 PR 解决，而 PR 又与问题相关。”

研究人员的方法（“利用PR 问题图拓扑结构揭示软件开发工作模式”）

基本 GitHub 工作流模式

经过这些项目的努力，研究人员发现了八种不同的工作流类型或行为模式，它们又构成了 1,000 多个开发操作实例。

团队中一位成员说道：“每一种工作流类型定义都与一种工作实践相关。”

研究团队发现的不同类型的工作流模式或行为的图表（“通过PR 问题图拓扑揭示软件开发工作模式”）。

毫不奇怪，35.7% 的关系类型都是解决简单问题。

他们发现的一种工作流类型是“竞争性 PR”：也就是两个或多个程序员分别提出一项功能，然后各自提交一个 PR。

在竞争性 PR 的情况下，“贡献者往往过于急于贡献他们自己的任务实现，但没有进行其他的沟通，”

只有一个 PR 被接受，说明该项目的沟通不够完善。因为有重复的工作，一个 PR 可能会因为对性能的阻碍太大而被拒绝，但另一个却被接受了。

然而，从好的方面来看，这种行为使得项目在接受 PR 时可以“更加挑剔”。

另一种模式：重复问题。这里指提出了多个问题，但彼此独立。如果你遇到了几个重复的问题，你就有了一个“重复问题中心”，这对项目来说是另外一个潜在的负面影响。

重大变更是导致问题中心重复的常见原因。这表明项目可以更清楚地传达即将发生的变更的信息。

Emilie Ma说道：

“重复问题中心的出现往往是因为贡献者不知道项目正在进行的工作，或者他们只是懒得搜索以前的问题。这会造成额外的维护负担，”

“它可能会被重新评估你的消息传递方式，改变导致重复的问题，以便更好地通知用户。”

但总体而言，重复问题出现的频率比您猜测的要低，研究人员在研究的 90,000 个节点中仅发现 15 个重复问题节点。

Emilie Ma 指出，有一个 Apache 开源项目创建了一个每周构建机器人，用来汇总该周合并的所有 PR 问题，以便让每个人都知道进行了哪些更新。

过于急切的开发者可能会导致另一种有问题的模式，即在单个 PR 中解决多个问题（分布性 PR），这可能会减慢团队的开发速度，因为这些多头 PR 需要更多时间来审核，因为审核者可能不熟悉正在解决的问题。

但是，并不是所有的模式都是有问题的。

为了添加重要功能，可以使用分解式 PR，它涉及的并非一个 PR，而是多个链接在一起的 PR。每个 PR 都是一项工作（“前端”）的一部分，可能依赖于其他 PR（“后端”）来完成问题。

通常，这些 PR 由同一位作者完成，他可以提交一个 PR，然后在第一个 PR 正在审核时开始另一个 PR。

这种方法通常被视为一种积极的模式，因为它使代码更易于编写、审查和提交，特别是对于较大的项目而言。

工作流类型如何反映出你的项目

总体而言，所有研究项目都存在工作流类型，但大型项目有更多的模式。这些项目中最大的项目有超过 150 种工作流类型。

Emilie Ma 表示：“项目的成熟度与其对结构化和高度组织化的协作的需求之间存在联系，这种联系体现在这些工作流程类型中。”

为了验证他们的发现，研究团队采访了许多项目开发人员，他们认为这种方法有助于改善代码审查和项目管理实践。例如，不同的 PR 可能表明需要更多代码审查优先级。

Emilie Ma 说：“可以将这个 PR/Issue Graph 视为一种Grafana，用来监控项目的协作健康状况，它可以帮助识别问题区域，并作为了解整个项目的全球参考点。”

详细介绍所有工作的论文“使用 PR 问题图拓扑揭示软件开发工作模式”将于7 月 18 日在巴西举行的 ACM 软件工程基础国际会议上发表。

Cleidson de Souza、Jesse Wong、Dongwook Yoon 和 Ivan Beschastnikh 是这项工作的共同作者。