代码评审与合并
新版合并请求自2023年8月起进入灰度测试阶段，本文档为您介绍新版合并请求说明。
1. 创建合并请求
创建合并请求由以下几个步骤组成：
选择来源和目标分支：用户根据需求选择源分支和目标分支，系统会提示是否存在差异（diff）或差异过大，为您提供详细的操作引导。
展示分支信息：选择完成后，系统展示所选分支的最新提交信息，包括提交时间、SHA等。
三个模块指引创建：
基础信息 ：提供合并请求的基本详情。
提交列表：列出相关的提交记录。
文件改动：显示具体文件的修改内容。
这三个模块帮助用户顺利完成合并请求的创建
1.1 基础信息
基础信息模板分为以下几个部分，用户可以根据需要进行编辑：
评审标题：默认会摘选提交信息中的标题进行自动生成。
标记为开发中（WIP）：在创建合并请求时，用户可以选择将其状态设置为“开发中（Work In Progress, WIP）”。处于WIP状态的评审不会向评审参与者发送通知，便于作者在前期频繁更新代码。当准备就绪后，作者可以通过移除标题中的[wip]前缀或在评审详情页取消WIP状态，将评审推进到正式的评审。
评审描述：用户可以填写评审的描述信息，目前Codeup有6种内置模板可供选择：
标准模板。
详细模板。
缺陷描述模板。
功能开发模板。
优化改进模板。
提交说明模板。
除此之外，还支持用户自定义合并请求模板功能，用户可以根据自己的需要进行定制，详情请参见评审描述与合并模板。
评审人编辑：支持在创建合并请求时，完成评审人的添加。同时提供了推荐的代码评审人信息，方便用户直接添加。
类标（Labels）：支持在创建新版合并请求时，完成类标的添加。
关联工作项：支持关联云效Projex中的需求、缺陷、任务等工作项类型。
1.2 提交列表
当切换到提交列表时，可以由近及远地查看各个提交信息，复制提交SHA以及进行提交详情页跳转。
1.3 文件改动
当切换到时，可以改动文件查看具体的文件改动差异。当一些准备就绪后，单击通过按钮便可以完成评审的创建。
2. 基于补丁（Patch）的评审工作流
2.1代码评审详情页首屏视图介绍
Codeup新版代码评审详情页的首屏视图，主要分为5个区块，下面将分别介绍各个区块。
2.1.1基础信息区-A
基础信息区-A的作用是，用户可以快速定位评审核心信息，以及评审流程操作入口。将其放置在评审视图的最顶端，符合用户评审工作流的关注顺序。方便用户查看具体信息以及执行高频操作：
查看和修改合并请求标题。
查看合并请求状态。
查看作者信息。
查看源分支（提交）和目标分支，支持对目标分支进行切换。
查看源分支相比目标分支的领先和落后的提交数。
单击“通过”或者“不通过”，进行评审表态。
单击“...”，包含的更多操作如下：
关闭合并请求。
下载合并请求。
设置WIP标记（取消WIP标记）。
2.1.2 基础信息区-B
基础信息区-B的作用是，让用户了解评审工作流的阻塞项和解决方案。基础信息区-B放在比较突出的位置，包含了当前评审继续推进到最终合并，还存在哪些问题，例如代码冲突问题，用户自定义的卡点门禁等。基础信息区-B的展示内容称之为“合并卡点信息”，各个评审的参与角色，都可以一眼洞悉当前评审的进程，并且知晓下一步action。
2.1.3 基础信息区-C
基础信息区—C的作用是，了解与当前评审的关联信息。关联的信息本质上不属于代码层面的元数据，而是为了辅助工作流运转的相关数据。例如，评审人展示和修改、类标的添加和删除、工作项的展示和关联（解除关联），这些信息通常不会非常频繁地修改，所以放置在右侧的次要位置。
2.1.4 基础信息区-D
基础信息区—D的作用是，让处于评审工作流的参与者，从不同的维度更细致地了解代码评审。因为首屏的信息的布局有限，对于不同维度的详细评审信息的展示问题，我们扩展了4个对应模块来解决，分别为：
概览：查看和编辑评审信息、查看和筛选评审动态、发表全局评论。
文件改动：查看具体改动的文件列表，文件内容diff。
提交改动：从提交的维度，查看评审的改动，包括列表和区间两个评审维度。
自动化检查：从CI/CD等维度，查看已集成的自动化检查的运行结果。
对比Codeup老版合并请求优势如下：
模块解耦：对比老版合并请求，整体产品模块的扩展性得到增强，针对评审各个模块得以内聚。
动态优先：我们新版的设计推荐用户关注评审的动态，尤其是评论的价值的展现和沉淀是重要的设计出发点。
体验更好：我们针对不同评审参与角色，考虑了整体视图上的区块划分，在满足高频信息浏览和操作的同时，我们努力让每一个参与者，都可以既了解评审的全貌，也可以清楚感知评审下一步目标。
2.2 评审状态流转
在代码评审的过程中，一般需要多轮次的评审改动，产品背后的逻辑是需要支持评审循环迭代过程中的状态轮转。简单清晰的评审状态机，在这里至关重要。新版合并请求中，我们简化了评审状态设计，总共抽象为4种状态，以下为各个状态的说明以及状态流转示意：
对比Codeup老版合并请求优势如下：
循环迭代：老版合并请求，当评审到达待合并状态之后，没有办法完成状态回退，即无法轮转回评审中（或开发中）的状态，进而难以进行多轮迭代。而在新版合并请求中，新的状态机可以很好的解决这个问题。
卡点生效：老版合并请求，当我们修改了合并卡点的配置，针对当前已经处于待合并状态的合并请求无法实时卡点生效，在新版代码评审中解决了这个问题，例如当处于紧急发布等场景，可以随时关闭和开启卡点设置，完成紧急情况下的代码合入。
2.3 评审更新的快照——补丁（Patch）
补丁（Patch）是Codeup新版合并请求的更新单位，每当用户对评审进行更新（例如，执行了一次git push）之后，Codeup会自动计算推送的最新提交与当前评审版本的比对，从而新生成一个评审版本，从而完成评审的更新。
不论评审的周期长短，每次只要用户对原分支的提交版本进行更新，Codeup都会自动为用户在保存已有版本的 Snapshot的同时，为用户生成新的 Snapshot，在 Git 的术语中，称为一个补丁（Patch）。在代码评审的流程中，在 Snapshot 中只记录 Git 相关的提交信息是远远不够的。因为评审往往存在多轮，即“循环迭代”的过程，通过一次代码评审的核心流程图，可以比较清楚地了解：
对于某一次Patch的评审，新版合并请求不仅仅会留下代码补丁对应的提交信息，还会衍生出其他一系列信息：
文件改动（代码Diff）。
评论。
自动化检查（CI）结果。
评审表态信息，如通过、不通过。
修改标题、描述、增删评审人等基础信息变更。
...
Codeup 会自动保存每个Patch衍生的全部信息，并且支持Patch与Patch之间的多维度信息对比，帮助解决评审颗粒度过粗，以及评审者难以从评审上下文中恢复，甚至经常需要重新进行Review的问题。在下面的文档章节中，我们对每一个产品模块，为大家进一步详细阐述基于Patch的评审工作流在其中发挥的关键作用。
对比Codeup老版合并请求优势如下：
针对循环迭代设计：与老版合并请求相比，让评审更新透明化、细颗粒化。
信息持久化：记录每一次评审更新的快照，沉淀快照衍生出的全部评审信息，轻松完成异步、增量评审。
支持Patch与Patch之间的多维度信息比对。
3. 文件改动模块
刚才我们介绍了基于Patch的评审工作流，下面我们看下如何使用文件改动模块的相关产品功能。
3.1 查看代码改动差异
当单击横向导航栏中的文件改动选项，我们将为您展示文件改动差异视图，主要分为三部分区块：
①处为补丁版本区间选择（Patch）：可以通过该组件灵活的完成Patch版本的区间切换。默认的，将为用户展示评审的合并基线（左侧“Base”，即来源分支与目标分支的Merge Base），以及当前最新补丁版本（当前评审最新Patch为“版本1”）之间的差异。
②处为文件树：可以通过该组件快速的完成评审文件树的浏览和切换。同时我们在文件上标识了三类信息，分别是：
文件修改类型。
已读和未读的信息标注（蓝色圆点）。
新增和删除的行数。
③处为差异视图：展示对应文件的改动差异。
3.2 文件改动的视图设置
不同的用户对于文件改动存在不同的评审习惯，针对类似的用户诉求，沿用并新增了部分视图方面的设置，并将自动记忆用户的配置习惯，其中包括：
Diff视图配置，切换单栏或双栏展示。
文件浏览模式配置，平铺模式或逐个浏览模式。
是否展示改动空格配置。
是否展示评论配置。
是否支持换行展示配置。
3.3 已读与未读
除了在文件树上展示关于文件的已读与未读信息之外，我们支持用户手动标注已读与未读信息，从而方便的记录自己希望额外关注或者多次阅读的文件。二者都是在基于Patch的评审工作流的基础上完成，即针对不同版本下文件的已读和未读的信息，codeup都将全部进行自动的持久化，不论用户如何切换版本，Codeup都将为用户展示特定补丁版本之下文件已读状态的准确信息，提升评审效率。
3.4 切换不同Patch之间的文件改动
针对一个已经创建的评审，若此时我们向分支执行了一次推送（例如，截图中修改了git-notes.txt文件并推送到评审的源分支）。新版合并请求会根据已经推送上来的提交，自动生成新的补丁，将代码评审自动更新为“版本2”。对于评审的参与者，可以在【红色框】的补丁版本组件上切换我们想要review的版本，如：Patch-1已经评审过了，当前只需要看Patch-1 和 Patch-2之间的差异即可，效果如下：
对比Codeup老版合并请求优势如下：
整体视图升级：得益于新版代码评审的模块化设计，我们有了更大的空间可以为用户展示文件改动信息，让用户在进行评审时更加专注。
上下文切换：通过已读未读、版本区间切换，评审者们很容易从此前的评审上下文中恢复，轻松完成针对增量的文件改动进行评审。
代码阅读器能力升级：我们完成了基于Monaco编辑器能力的升级，在对文件改动进行评审时，整体的阅读体验完成了较大的提升。
4. 提交改动模块
当文件改动量较小时，评审者可以通过直接查看文件改动高效完成评审。然而，对于大规模的文件改动，评审的复杂度和难度会显著增加。为解决这一问题，新版合并请求引入了“提交改动”选项，帮助用户从提交维度入手进行评审，提升效率。
提交列表： 类似
git log命令，由近及远地展示特定Patch提交列表。版本差异： 类似
git range-diff，查看两个Patch之间的提交改动信息。
在提交改动模块中，依然保留了基于Patch评审工作流的痕迹。提交列表和版本差异视图均支持切换评审中的Patch版本。提交列表适合首次评审场景，用于对所有提交进行全量评审；而版本差异视图则更适合多次补丁迭代评审，帮助评审者聚焦版本变化，进行增量评审。有关这两种工具的不同使用场景，已在文档通过 “提交列表” 快速了解最新改动，进行全量评审中详细说明，建议阅读以获得更多
Codeup新版合并请求相较于老版具有显著优势，主要体现在其版本差异视图功能上。
该视图能够直观展示两个不同分支或提交序列之间的差异，相比传统的`git diff`命令，它不仅展示了两个特定状态之间的差异，还能呈现一系列变更的全貌。这使得评审者可以专注于新的更改，避免重复审查已检查过的代码，并更容易理解每个变更。
5. 自动化检查模块
Codeup 提供了开箱即用的流水线和代码检测功能，使用户能够快速且低成本地集成CI服务。用户可以通过点击横向导航栏上的自动化检查选项，查看合并请求中自动化检查的运行结果，并通过切换代码评审Patch版本追溯历史检查结果。自动化检查支持三种集成方式，详细介绍分别如下：
云效Codeup代码检测集成。
云效Flow流水线集成。
三方自动化检查集成。
5.1 云效Codeup代码检测集成
Codeup内置诸多代码检测能力，支持与代码评审进行轻松集成，可参考代码检测。Codeup代码检测集成后，支持如下几个能力：
支持代码检测状态实时回写。
支持代码检测运行详情的前端嵌入，提升使用体验。
支持快捷跳转到Codeup代码检测任务详情页。
5.2 云效 Flow Pipeline 集成
Codeup代码评审支持与云效Flow进行轻松集成，具体可参考文章如何关联Flow流水线。云效Flow流水线完成集成后，代码评审支持如下几个能力：
代码评审展示的流水线的状态为实时回写，并会在页面自动完成更新。
支持云效流水线运行详情的前端嵌入，提升使用体验。
支持快捷跳转到云效流水线详情页。
5.3 三方自动化检查服务集成
5.3.1 基于提交状态（Commit Status）能力进行三方CI集成
5.3.1.1 基于OpenAPI完成数据回写
本章节介绍Codeup平台的三方CI集成功能，允许用户通过提交状态（Commit Status）的OpenAPI接口回写CI结果数据。这些结果将自动集成到代码评审的自动化检查中，作为三方自动化检查结果展示，称为“三方提交状态”。具体功能包括：
状态回写：支持回写四种状态：success、failure、pending、error。
链接回写：支持回写链接，便于跳转查看详细的执行信息。
描述回写：支持回写描述信息，并可使用Markdown格式进行渲染。
更多详情可参考API文档CreateCommitStatus - 添加提交状态记录。
5.3.1.2 基于提交状态（Commit status）设置合并卡点
在日常开发中，可以通过设置提交状态的卡点，以阻止不满足卡点要求的合并请求进行合并。该配置在库中，如下图所示：
对比Codeup老版合并请求优势如下：
开放提升：支持三方CI等服务轻松集成。
历史追溯：支持切换查看历史Patch的运行结果，鼓励开发者频繁地提交代码。
体验优化：云效Flow流水线运行详情支持内嵌展示、Codeup代码检测运行详情支持内嵌展示、三方检查支持Markdown的描述详情渲染。
实时增强：任一类型的自动化检查结果进行实时更新渲染，无需刷新页面。
5.3.2 基于检查运行（Check Runs） 能力进行三方CI集成
除了传统的提交状态（Commit Status）进行三方CI集成的方式，Codeup还引入了“检查运行（Check Runs）”作为另一种更高级的集成方式。提交状态虽然简单易用，但对于需要精细职能分工和严格评审流程的团队来说，功能较为有限。检查运行特性提供了更强的扩展性和定制化能力，支持丰富的CI状态枚举、检查注释（Check Annotations）以及自定义结果展示视图（基于Markdown格式）。整个检查运行的生命周期通过OpenAPI进行设计和实现，详细的API信息可参考检查运行。。
5.3.2.1 Check Runs支持丰富的CI状态
检查运行（Check Runs）的状态通过两个参数字段 status 和 conclusion决定，用户在使用时，可以根据实际自动化检查结果进行状态映射。
status包含：queued：排队中。
in_progress：运行中。
completed：已完成。
conclusion包含（当status为completed时，conclusion才会写入生效）：cancelled：已取消。
failure：失败。
neutral：中立状态（通常该状态用于「需要执行自动化检查，但不影响最终结果或可以忽略」，计为成功状态）。
success：成功。
skipped：跳过（计为成功状态）。
timed_out：超时（三方检查的超时时间）。
stale：过时（由代码平台决定，超过14天且状态仍然未达到status=completed时，会被平台处理为stale，并且只有代码平台才能将check runs的conclusion设置为stale，用户无法通过回写设置该状态）。
5.3.2.2 检查输出（Check Ouput）能力介绍
用户通过OpenAPI回写output字段，可以定制化某一个检查运行（Check Runs）的详情展示。如果您存在类似的个性化诉求，此部分是UI展示的重点信息字段：
output包含：title：标题信息（非check runs的name）。
summary：摘要信息，支持 Markdown格式，最大字符长度为64KB，即65535个字符。
text：详情信息，支持Markdown格式，最大字符长度为64KB，即65535个字符。
images：该字段为需要展示的图片信息，通常不超过3张图片，并且需要确保能够被访问，否则可能无法展示。
以下为output回写时，检查运行对应的展示：
5.3.2.3 检查注释（Check Annotation）能力介绍
检查注释提供了在代码检查中直接针对代码行、或者连续的代码片段进行注释信息添加的能力。在实践中，当CI可以返回具体代码行位置的问题时，通常也希望在评审界面也能直观地了解。检查注释通过OpenAPI进行回写，下面是具体的字段介绍：
annotations包含：path：文件路径。
startLine：开始行，从1开始，这需要用户确保该行能够在path指定的文件中找到。
endLine：结束行（同上）。
startColumn：起始列（当且仅当startLine=endLine时，该字段有效）。
endColumn：结束列（当前仅当startLine=endLine时，该字段有效）。
annotationLevel：检查注释问题等级：
notice：轻微。
warning：警告。
failure：严重。
message：检查注释的摘要信息。
title：检查注释的标题（这不是必需的，但在实践上，我们建议标题用于指明代码行和问题，便于快速了解问题）。
rawDetails：CI运行输出的原始内容（作为普通文本格式不会进行特殊的渲染，限制64KB）。
检查运行详情页展示：
代码评审差异（Diff）视图的展示：
5.3.2.4 基于检查运行（Check Runs）设置合并卡点
在代码库左侧导航栏底部，选择，进行新增：
如果刚完成合并卡点的配置，此时还未有相应的检查运行数据回写，我们将会做如下展示（对应代码评审卡点项，Codeup基本保持了相同的逻辑，即卡点项一旦配置一定会在自动化检查中展示，即使它没有当前版本的检查记录）：
当回写数据后的产品展示：
没错，如果在保护分支中配置了自动化检查卡点，那么在合并请求的自动化检查导航栏下，相应的自动化检查项会被标记为卡点。除此之外，只有卡点项才会影响合并请求的合并准许，非卡点项仅展示，但不会阻塞，不过，我们并不建议您对「失败的非卡点项」忽略。
6. 评论能力介绍
新版代码评审，提供了诸多的评论能力，评论能够帮助参与评审的各个角色进行更好的反馈和响应，它不仅有助于提高当前的代码质量，还有助于团队的持续学习和进步。
6.1 评论的状态与展示
当评论发出后，可以复制评论链接，方便分享。也支持针对评论内容再次编辑，或者删除。对于一个已发送的评论来说，大体可以分为两种状态：
待解决：默认会进行视图展示，目的是帮助用户直观和快速定位待解决评论，用户可以单击标记为已解决按钮更新评论状态为已解决。
已解决：默认我们会置灰并进行收起，目的是帮助用户屏蔽干扰（已解决通常意味着后续无需再关注），用户可以单击标记为待解决按钮更新状态为待解决。
6.2 行内评论（文件评论）
上面介绍的例子，其实是行内评论演示。行内评论主要用于提供具体文件改动位置的针对性的反馈，使得讨论具体而集中。
6.3 全局评论（整体评论）
全局评论也可以叫做整体评论，通常指的是针对整个评审进行的评论。它们用于提供更高层次的反馈，涵盖整体上的问题或讨论，或者讨论更加广泛的、衍生的主题。全局评论的入口位于动态底部，整体评论和行内评论在动态中有明确的样式区分。
6.4 上下文回复和提及
不管是行内评论还是全局评论，都支持基于评论上下文进行回复，同时也可以提及其他用户参与讨论。
6.5 草稿评论
草稿评论是代码评审过程中一个非常实用的功能，草稿意味着评论并没有实际发出，而只是对自己可见。草稿评论可以帮助评审者更加有效和有组织地提供反馈，它是一个思考和准备步骤，确保提交的评论是经过深思熟虑的，更有助于代码质量的提升。
草稿评论为淡黄色，与非草稿评论进行了明确的样式区分，草稿评论同时也支持针对内容本身进行更新，或删除。当草稿评论准备完毕，可以单击右上角提交草稿进行批量提交，单击后会展示如下信息：
文件名、评论行号（支持单击跳转）。
基于的Patch的版本。
草稿评论的缩略信息。
当确认无误后，单击立即提交，草稿评论即可发出，进而提供给其他评审者进行反馈。
6.6 动态表情评论
动态表情可以帮助传达语气和情感，使评论更具人情味，减少因文字表述不当而引起的误解，增强沟通效果，减少接受反馈时的心理压力。新版代码评审，支持4种动态表情评论分别表示：
LGTM（Looks good to me！）。
赞同。
已阅。
存疑。
6.7 评论的快速筛选
有时我们希望能够针对特定的评论进行筛选，例如快速定位待解决的评论，或者特定评审者需要关注的评论。Codeup新版合并请求，支持基于评论者、评论状态以及是否被提及，进行快速筛选，提升评审效率。
6.8 待解决评论的迅速定位
为了更进一步快速处理待解决评论等待办事项，我们在右上角的位置放置了一个常驻的待解决小组件，不论用户当前身处哪个模块之下，都可以基于此组件完成待办事项的快速定位。用户只需要单击“向下”的箭头，便可以逐一的处理评审待办事项。除此以外，单击组件本身，将会具体展示不同类型的待解决问题列表，并支持单击跳转到对应位置。
对比Codeup老版合并请求优势如下：
丰富的评论筛选能力。
“待解决”提效组件支持快速定位待解决评论。
支持动态表情等更多评论能力。
评审产品交互体验得到大幅提升。
7. 卡点门禁能力介绍
7.1合并卡点配置
新版代码评审系统兼容轻评审和重评审流程，支持灵活配置卡点门禁，并实时生效。系统严格依据用户要求的合并条件执行合并操作。此外，系统提供4种通用卡点场景配置，用户可在保护分支设置中灵活选择。
代码冲突卡点。
评审通过人数卡点。
自动化检查卡点。
评论未全部解决卡点。
7.2 卡点信息的展示
配置合并卡点后，触发对应提交时，新版代码评审将进行重点提示。本文将具体介绍四类合并卡点。
7.2.1 代码冲突卡点与在线冲突解决
当存在代码冲突时，鼠标hover到代码冲突卡点时，将会提示冲突解决的解决方案，我们提供了两种解决冲突的方式：
使用在线冲突解决功能。
本地更新下载最新代码并解决。
如果冲突内容较多，推荐在本地进行冲突解决。
7.2.2 评审通过人数卡点
当将鼠标hover评审通过人数不足的卡点时，将展示评审通过情况。
7.2.3 评论未全部解决卡点
当单击评论未全部解决卡点时，将自动为我们切换为概览视图，并自动筛选出动态中的待解决评论。
7..2.4 自动化检查未通过卡点
当我们鼠标单击检查卡点未通过时，将自动为我们切换为自动化检查视图，为我们呈现自动化检查运行情况。
对比Codeup老版合并请求优势如下：
体验提升：合并卡点信息更加直观明确，交互体验便捷高效。
三方集成：支持三方自定义检查作为卡点与新版代码评审进行集成。
8. Revert（回撤）与 Cherry-Pick（拣选）
Codeup提供强大的分支管理和协作功能。合并请求是其核心功能之一，主要用于代码评审、讨论和合并代码。在合并请求中，Revert和Cherry-pick是两个非常实用的操作。
8.1 Revert
Codeup新版代码评审的Revert功能允许用户回撤已合并的代码。当合并请求中包含错误或不期望的更改时，可通过Revert操作撤销。Codeup提供两种Revert方式：
直接Revert；
生成一个用于Revert的新分支，创建新的合并请求以还原之前合并的代码。
8.2 Cherry-pick
新版代码评审引入了Cherry-pick功能，允许用户对已合并的代码进行挑选处理，特别适用于bug修复或特定功能在不同分支间的迁移。Codeup提供了两种方式来Cherry-pick某个合并请求：
直接Cherry-pick。
创建一个专门用于Cherry pick的分支，并从该分支发起一个新的合并请求，以将原合并请求中的代码挑选（Cherry pick）到指定的目标分支。
Cherry pick功能支持选择是否压缩提交。如果选择压缩提交，所有提交将被合并为一个提交并应用到指定分支；如果不选择压缩提交，则每个提交将逐个应用到指定。
9. 代码评审下载与本地应用
在新版合并请求详情页面上，您可以获取代码变更内容。以下是快速获取代码变更内容的步骤：
访问合并请求详情页面。
单击“下载合并请求”按钮，此举会引导您进入查看界面。
在版本选择下拉框中选择源分支特定版本。例如：若选择版本 1，则会获取目标分支与源分支版本 1 之间的变动内容。
具体请参考以下示意图：
我们共提供了 4 种获取合并请求改动内容的方案，下面我们将一次介绍：
方案1—下载并检出到新分支
Tab 1 正文执行下述命令，将从远程下载特定的合并请求引用refs/changes/<mr-id>/<patch-id>， 然后在本地仓库中创建一个新的分支<branch-name>并切换到这个新分支上去。
git fetch origin refs/changes/<mr-id>/<patch-id> && git checkout -b <branch> FETCH_HEAD注意：当您想要在本地查看或继续工作在这个特定的变更上，并且希望这些变更在一个新的分支上进行时，您会使用这个命令组合。
方案2—下载并检出到提交号
执行下述命令将从远程仓库 origin 下载特定的代码变更引用refs/changes/<mr-id>/<patch-id>，然后在本地仓库中检出该修改，即把工作目录更新为该修改的内容。
git fetch origin refs/changes/<mr-id>/<patch-id> && git checkout FETCH_HEAD注意：这个命令不会创建新的分支，当您想要临时审查或测试一个变更，且不打算在这个变更的基础上进行长期工作时，您可能会使用这个命令。
方案3—下载并拉取到当前分支
执行下述命令将从远程仓库 origin 下载特定的代码变更引用refs/changes/<mr-id>/<patch-id>，然后把拉取的变更合并到本地的当前分支中，这个命令实际上是 git fetch 和 git merge 的结合体。
git pull origin refs/changes/<mr-id>/<patch-id>方案4—下载文件
下载文件的两种不同格式：
单击 “补丁（Patches）文件” 下载链接即可下载对应的补丁文件。
单击 “差异（Diff）文件” 下载链接即可下载对应的差异文件。
注意：为确保下载流畅，Patch/Diff 总文件的大小上限为 24MB，超过大小则会下载失败。如果需要，我们强烈推荐您选择前面三种方案，或者在本地手动生成 Patch 或 Diff 文件， 可以执行下述命令：
git format-patch <from-commit>..<to-commit> --stdout >changes.patch上述命令会在您的本地生成一个名为 changes.patch 的补丁文件，其中包含了<from-commit>和<to-commit>之间的变更。
git diff <from-commit> <to-commit> >changes.diff上述命令会在您的本地生成一个名为 changes.diff 的差异文件，其中包含了<from-commit>和<to-commit>之间的差异。
Patch/Diff 文件的差异
Diff文件
Diff文件用来展示两个提交之间的差异，或是比较工作目录中当前文件和索引（或指定 commit）的差异。它通常用于本地查看修改或准备将变更加入暂存区的过程中。它是一个纯文本格式的差异描述，这个格式被称为unified diff。该输出通常包括行前缀 + 表示添加的行，- 表示删除的行。如下展示的是一个具体的Diff文件：
Patch文件
Patch文件是一系列的补丁文件，每个补丁对应一个或多个commit。这些补丁文件是可以通过电子邮件发送并应用到另一个仓库的。Patch文件不仅包含代码差异信息，还包含了 commit 信息（如作者、日期和commit消息等），以及用于邮箱格式的额外头部信息。如下展示的是一个具体的Patch文件：
在Git的世界里，Diff和Patch文件在本质上承载着相似的任务，即准确地记录代码的变更。当决定使用哪种文件时，您的目标决定了您的选择：如果您的目的仅仅是为了审视代码之间的不同，Diff文件本身就能满足需求；但如果您需要将一连串的修改共享出去，或者想要将这些更改迁移到另一个代码库，Patch文件便显得尤为合适。这种格式不仅包含了变更的详细内容，还携带了足够的信息来支持跨环境的版本控制协作。
如何应用 Patch/Diff 文件到本地仓库进行评审？
离线代码审查
使用Diff文件进行离线审查，以便在无需网络连接的情况下检视代码差异，并进行代码评审。
使用git apply应用补丁
切换至本地代码库目录：
cd /path/to/your/repository使用以下命令应用Patch文件：
git apply /path/to/changes.patchgit apply命令支持多个选项，例如：–stat：显示补丁文件的变更统计信息。
–check：检查补丁文件是否可被应用，而不实际执行应用。
–apply：实际应用补丁（通常为默认操作，一般无需指定）。
–whitespace=option：检查空白字符错误。
–reverse：反向应用补丁。
使用git am应用补丁
切换至本地代码库目录：
cd /path/to/your/repository使用以下命令应用Patch文件：
git am /path/to/changes.patchgit am命令还有一些实用的选项，例如：–signoff(-s)：在提交的末尾添加一个“Signed-off-by”行，表明您有权提交此补丁，并同意相关协议。
–3way(-3)：如果补丁不能直接应用，则尝试三方合并。
–skip：跳过当前补丁。
–resolved：在解决冲突后，告诉 Git 继续应用下一个补丁。
如果在应用补丁的过程中发生冲突，git am 将停止应用补丁，并允许您手动解决冲突。解决冲突后，可以使用如下命令来继续应用补丁：
git am --resolved或：
git am --continue要放弃补丁的应用并恢复到原始状态，可执行：
git am --abort
对比Codeup老版合并请求优势如下：
支持合并请求下载能力。
支持多种下载方式，用户可基于使用习惯灵活选择。
10. 代码评审模板管理与定制
Codeup新版代码评审支持灵活定制的描述信息模板以及合并提交模板，具体参考文档：评审描述与合并模板。
11. 推送评审模式
Codeup提供了一种便捷的代码评审机制，允许用户通过执行原生的git push命令自动创建和更新代码评审，而无需安装额外工具或在远端创建分支。该功能支持对提交进行评审，简化了代码合并流程。详情可参考文档推送评审模式。
$ git push
枚举对象中: 4, 完成.
对象计数中: 100% (4/4), 完成.
使用 12 个线程进行压缩
压缩对象中: 100% (2/2), 完成.
写入对象中: 100% (3/3), 340 字节 | 340.00 KiB/s, 完成.
总共 3（差异 0），复用 0（差异 0），包复用 0
remote: +-----------------------------------------------------------------------------------+
remote: | The following tips are provided by Codeup: |
remote: +-----------------------------------------------------------------------------------+
remote: | Merge request #31620 has been updated, please visit: |
remote: | https://codeup.aliyun.com/61234c2d1bd96aa110f27b9c/demo/merge_request/31620 |
remote: +-----------------------------------------------------------------------------------+
To https://codeup.aliyun.com/61234c2d1bd96aa110f27b9c/demo.git
27e76f582c..e00db4522f master -> refs/merge-requests/31620/head12. 分支标签评审模式
代码评审与合并通过推送评审来管理仓库中的代码变更，防止代码被随意修改。然而，拥有写权限的用户仍可创建、删除分支或标签，导致仓库中的分支和标签逐渐变得混乱，出现许多过期无用的分支，影响日常维护并降低研发效率。
通过使用分支标签评审模式，可以有效防止直接创建、删除分支和标签的操作，即使用户具有相应权限。所有变更需通过评审流程进行管理，从而实现更好的管控。新版代码评审已支持该功能，详情请参考相关文档分支标签评审模式。
13. 开放性
13.1 OpenAPI
Codeup新版代码评审，开放了以下的OpenAPI：
创建代码评审。
通过代码评审。
更新代码评审。
查询评审状态。
查询代码评审列表。
创建评论。
更新评论。
查询评论列表。
查询代码评审设置。
具体请参见文档：合并请求。
新版合并请求对评审核心模型进行了修改，导致OpenAPI和WebHooks存在部分不兼容变更。使用相关功能的用户应查看对应文档以了解新旧版本的差异。具体文档包括：
新版和老版合并请求Webhooks格式文档。
请参考以上文档以确保系统的兼容性和正确性
13.2 WebHooks
Codeup新版代码评审，支持订阅多种类型的WebHook事件：
创建事件。
更新事件。
评论事件。
合并事件。
表态事件。
具体请参见文档：Webhooks设置。
13.3 关联类标（Labels）
Codeup提供了类标功能，类标可以作为一种特殊的标记关联到合并请求中，存在以下两种途径：
在创建合并请求时，在类标字段选择您想关联的类标。
在合并请求的详情页面，在右侧的类标区域，来选择类标关联或者删除已关联的类标。
同时，在合并请求的动态中也会记录关于类标的操作，如下图所示：
14. 类标在评审协作中的作用
14.1 便于协作和沟通
在团队协作方面，类标可以提供明确的沟通途径和状态更新。当一个团队成员给合并请求分配一个“待复审”的类标时，其他人可以知道这个合并请求已经准备好由另一个成员进行复审。
14.2 自动化和集成
通过使用类标的OpenAPI并且结合自动化工具，你可以自动化某些基于类标的操作，比如当合并请求获得特定类标时，自动启动部署或测试流程。
15. 合并请求列表页升级
15.1 合并请求列表支持显示评审尺寸
在合并请求页面上，您可以直观地看到改动的大小。我们通过计算改动行数，并将其量化成5个级别，帮助用户了解改动。
新版的合并请求页面支持展示以下五个改动尺寸级别：
XS（小于10行）：这个级别适用于非常小的改动。它可能只是一行或几行代码的修改，或者是一个非常小的修复。S（大于等于10行小于50行）：如果改动的行数在10到50行之间，它将被归类为S级别。这意味着它是一个中等大小的改动，可能是一个小功能的添加或一个简单的重构。M（大于等于50行小于250行）：当改动的行数在50到250行之间时，它被认为是M级别的改动。这可能是一个较大的功能添加、一个模块的重构或一系列相关的改动。L（大于等于250行小于1000行）：如果改动的行数在250到1000行之间，那么它属于L级别。这表示它是一个相当大的改动，可能涉及多个模块或子系统的修改。XL（大于等于1000行）：如果改动的行数超过1000行，那么它被认为是XL级别的改动。这意味着它是一个非常大的改动，可能是一个全面的重构、一个新功能的完整实现或者是一个庞大的代码库的更新。
我们还通过将这五个级别的改动大小展示在图案中，帮助用户更好地了解改动的具体尺寸。当鼠标悬停在大小的图标上时，可以查看具体的尺寸。通过这五个级别的改动大小显示，您可以更好地评估合并请求的规模和复杂性。这将帮助您更好地了解改动的程度，并相应地进行资源分配和测试计划。
15.2 根据多种维度对合并请求进行筛选
15.2.1 根据类标进行筛选
产品示意图：
15.2.2 根据评审类型进行筛选
产品示意图：
15.2.3 根据发起人或评审人进行筛选
产品示意图：
