拉取请求评审流程桑基图：从大小到合并
看拉取请求如何从大小，经过首次评审结果，走向合并、返工或废弃。换成你自己的仓库数据，找出评审在哪里停滞。
拉取请求桑基图显示变更被提出之后的去向：一次通过、退回返工，或被关闭。按大小分组后，可以看出是不是大变更拖慢了评审。
示例有 250 个拉取请求：120 个小型、90 个中型、40 个大型。首次评审后，130 个获批，90 个被要求修改，30 个未经评审就被关闭。最终 198 个合并，12 个废弃，10 个仍未关闭。
宽度让大小的代价看得见：120 个小变更中有 90 个一次通过，而 40 个大变更中只有 5 个。这里返工路径是一条流，而不是循环，所以被退回两次的请求仍只按其最终结果算一次。关于这些变更触发的构建会怎样，请看 /zh/sankey/ci-pipeline-outcomes。
如何阅读此图表
- 250 个拉取请求中有 198 个（79%）最终合并；12% 未经评审就被关闭。
- 小变更有 75%（120 个中的 90 个）一次通过，大变更只有 13%（40 个中的 5 个）。
- 被退回的 90 个变更中有 70 个（78%）返工后合并；12 个被废弃。
- 仍有 10 个请求未关闭，其中 8 个在被要求修改后一直在等待。
图表背后的数据
数字为虚构，仅作说明，并非任何真实机构、团队或系统的数据。单位为拉取请求。
| 来源 | 目标 | 数量（个拉取请求） |
|---|---|---|
| 小型（少于 100 行） | 一次通过 | 90 |
| 小型（少于 100 行） | 被要求修改 | 22 |
| 小型（少于 100 行） | 未经评审关闭 | 8 |
| 中型 | 一次通过 | 35 |
| 中型 | 被要求修改 | 45 |
| 中型 | 未经评审关闭 | 10 |
| 大型（超过 500 行） | 一次通过 | 5 |
| 大型（超过 500 行） | 被要求修改 | 23 |
| 大型（超过 500 行） | 未经评审关闭 | 12 |
| 一次通过 | 已合并 | 128 |
| 一次通过 | 仍未关闭 | 2 |
| 被要求修改 | 已合并 | 70 |
| 被要求修改 | 已废弃 | 12 |
| 被要求修改 | 仍未关闭 | 8 |
同样的数据（CSV）
source,target,value
小型（少于 100 行）,一次通过,90
小型（少于 100 行）,被要求修改,22
小型（少于 100 行）,未经评审关闭,8
中型,一次通过,35
中型,被要求修改,45
中型,未经评审关闭,10
大型（超过 500 行）,一次通过,5
大型（超过 500 行）,被要求修改,23
大型（超过 500 行）,未经评审关闭,12
一次通过,已合并,128
一次通过,仍未关闭,2
被要求修改,已合并,70
被要求修改,已废弃,12
被要求修改,仍未关闭,8运作方式
导出一个周期的拉取请求
包含修改行数、首次评审结果和最终状态。取一个季度或一个版本。
按大小分组
选两三个大小区间并说明怎么划分。每个请求只算一次。
统计首次评审和最终结果
中间一列用首次评审结果，最后一列用最终状态。
检查平衡
每个中间节点流出的请求数必须等于流入的。未经评审关闭到此结束。
常见问题
为什么不把评审轮次画成循环？
因为宽度代表计数，循环会让同一个请求被算两次。如果轮次很重要，可以另做一张图，把轮次数作为中间一列。
图里显示评审速度吗？
不显示。宽度是计数。可以把首次评审用时放在图表旁边的表格里，或另画一张按时间段划分的图。
编辑这张拉取请求桑基图
把示例作为你自己的图表打开，填入你仓库的计数。