使用合并请求

步骤一：新建合并请求

1. 在合并请求列表页单击新建合并请求，单击后展现新建合并请求对话框，需要填写创建合并请求基础信息。

   配置项	描述
   来源	期望被合入的来源分支。
   目标	期望合入的目标分支。
   标题	合并请求的标题。
   描述	说明合并请求的背景、业务依赖等。
   评审人	选择指定期望评审的人员。 若设置默认评审人（详见分支设置），则自动填写默认评审人。 若开启CodeOwner机制（详见 CodeOwner 机制），则将自动回填已匹配的CodeOwner，且需要至少一位CodeOwner评审通过。如果CodeOwner未匹配任何仓库成员，则需要至少一位评审人评审通过。
   类标	支持在创建新版合并请求时，完成类标的添加标识。
   关联工作项	关联云效项目中的工作项，以辅助说明合并请求的背景。

2. 在以上信息填写完成后单击确定，完成合并请求创建。

步骤二：通过合并请求

• 解决代码冲突：当合并的分支存在代码冲突时，系统会自动卡点，无法进行合并操作。Codeup提供了两种冲突解决方式：

  命令行方式

  # 步骤1 fetch并切换到源分支
  git fetch origin
  git checkout -b sourceBranch
  # 步骤2 合并目标分支
  git merge origin/master 
  # 步骤3 解决冲突并push
  git add <conflicted-file>
  git commit
  git push origin main

  冲突在线解决

  打开在线冲突解决，系统会默认展示本次合并发生冲突的文件和冲突的代码字段，您直接手动修改即可。进入冲突在线解决页面后，页面显示正在解决 feature/scan 到 master 分支的代码冲突。左侧面板列出冲突文件（如 file.txt），右侧主区域展示该文件的冲突内容，包含 <<<<<<< master 与 >>>>>>> 冲突标记。代码区域上方提供三种解决方式：使用当前的改动、使用传入的改动、保留双方的改动。解决所有冲突后，单击右上角提交改动按钮完成合并。

• 评审人卡点：当评审人通过数量小于设定值时，系统会进行卡点。评审人卡点设置参见代码评审规则设置。

• 评论：待解决的评论可通过展开待解决面板查看，单击评论将自动定位到对应版本的评论处。

  在评论下方单击标记为已解决可将该条评论标记为已解决。

  输入行评论可直接发布或存为草稿，草稿仅自己可见，评审后完成评审进行多份草稿的统一提交，提交后他人可见。

  合并请求详情页中，当存在代码冲突时，页面顶部显示无法合并和代码冲突未解决状态标签。在文件改动页签中可查看各文件的 diff 对比视图，评审者在变更行旁发布的行评论将直接展示在对应代码行右侧。

• 自动化卡点：自动卡点包括代码检测任务卡点和自动化流水线卡点，设置方式请参见自动化执行检查。

  设置后，合并请求更新可触发自动化代码检查，辅助代码评审。检查结果可单击查看详情：

  在自动化检查 Tab 页中，顶部汇总展示检查不通过、运行异常、运行中及检查通过的数量。左侧列出各检查项（如云效流水线、云效代码检测）及其通过或失败状态，主区域展示选中流水线的各阶段任务执行详情，包括Java 代码扫描、Maven 单元测试、Java 构建 Docker 镜像并推送镜像仓库等任务的运行结果。若某任务运行失败，可单击重试重新执行；当存在未通过的检查时，合并请求显示检查卡点未通过，合并按钮不可用。

• 评审结果表态

  有权限通过的评审人单击完成评审展现评审意见面板，进行以下评审表态：

  • 单击通过按钮表示认可并通过评审。

  • 单击暂不通过表达认为需要修改，暂不允许合并，后续对方更新代码后可再次通过评审。

  • 单击仅评论则表示不表态，仅发表评论看法。

  表态时可以一并发送草稿评论，提交评审意见。

  合并请求的状态栏中，若显示评论未全部解决，则无法执行合并操作。需在评论区找到状态为待解决的评审评论，确认处理后单击标记为已解决按钮，待所有评论解决后方可合并。

步骤三：合并分支

在所有合并卡点都通过后，可进行合并操作。单击右上角的合并按钮，选择合并模式并提交。