1. 项目协同
  2. 代码仓库
  3. DevOps 实践之旅
  4. 一分钟开始持续集成之旅
  5. 持续部署
  6. 制品库

合并请求与代码评审

在采用多分支开发工作流时,建议开发组长将主分支设置为保护分支,开发者创建临时开发分支,完成后向主分支发起合并请求。通过持续集成和代码评审后,开发者将开发分支合并至主分支。

新建合并请求

支持使用命令行创建或手动创建合并请求。

通过命令行创建:

git push origin local-branch:mr/target-branch/local-branch

手动创建:

在 Web 端手动创建,需选择目标分支和源分支,当源分支的提交不领先于目标分支时,不可创建合并请求。当系统显示为可合并时,才能创建合并请求。

你可以填写本次合并请求的标题、描述或相关附件等项目内资源,选择分支管理员或相关成员作为评审者。待评审者确认无误后可以点击允许按钮,发起者即可合并分支完成此部分代码提交。

合并状态提示

可自动合并

当源分支与目标分支对比后没有发现冲突,代码对比将展示它们之间的差异,并提示该分支可自动合并,可以创建合并请求并在线合并分支。

不可自动合并

当源分支与目标分支对比后发现存在冲突,代码对比将展示它们之间的差异,并提示该分支不可自动合并,可以创建合并请求,但需解决冲突后才能继续合并分支。

例:当 branch-01 合并入 master 分支时提示有冲突时,可以先在本地切换至 master 分支并运行命令:

$ git merge branch-01

找到冲突文件,此时冲突文件会标识冲突内容并询问保留何种内容。选择需保留的内容,保存后重新提交 commit,完成后切换至 branch-01 分支并输入命令:

$ git merge master

再将修改后的代码推送至远端仓库即可。

代码评审

开发者可在新建合并请求时或合并请求合并前,更新标题和描述,添加其他项目成员为评审者,并关联项目内资源(如任务、文件、合并请求、Wiki)。点击阅读如何自动添加评审者

评审内容

评审者收到邀请评审通知后,对代码进行评审的内容一般会聚焦于以下两点:

  • 该合并请求的标题、描述及关联资源是否对代码改动作出充分说明,评审者可通过评论和发起者进行沟通确认。
  • 针对提交记录对应的文件改动,进行代码行级评审(评论)。

代码行级评审

鼠标悬停在代码文件中的某一行,界面会显示出 + 号,点击即可针对该代码行发起评论。评论提交后,提交代码改动的团队成员将会收到您的评论通知,当他回复评论后,您也会收到评论通知。由此,开发者可通过代码行级评论就某一行代码进行讨论交流。

状态检查

除了上述常见的人工代码审查外,结合 CODING 持续集成,我们还提供了自动化代码评审工具集成的解决方案。基于预定义的规则先行对代码进行扫描,当代码质量有问题时会拒绝合并代码,只有通过了自动化工具检查的代码才允许合并,显著提高代码审查效率。

开启状态检查

保护分支支持开启状态检查,勾选之后,要求状态检查(CI 任务)全部运行通过后才允许合并。

在持续集成中的触发规则内需要选中「创建合并请求时触发构建」,这样才能在创建合并后立即触发构建任务。

查看状态检查

完成上述设置后,在正确触发构建任务的情况下,可以看到正在执行的任务状态。如果没有显示如图界面,可能是没有在 CI 构建任务中选择「创建合并请求时触发构建」。

您可以点击右上角的刷新按钮随时获取最新状态,成功后会在下方出现分支已经合并的提示,失败则会拒绝合并。状态检查有四种状态:

  • 正在执行中,您可以耐心的等待构建完成。
  • 成功,此时合并请求可以正常合并。
  • 失败,构建过程发生错误,合并检查不通过,您可以修改代码、推送触发新的构建任务直到构建成功完成。
  • 异常,构建过程发生了异常,可以尝试进行手动触发。

如果存在多个状态检查的情况下,只有所有的状态检查都成功通过后才会允许分支合并。您也可以在代码浏览、提交历史、分支列表中查看状态检查过程。

合并确认

  • 合并的目标分支为保护分支

若合并请求的发起者为分支管理员,那么可以自行合并。若发起者为普通成员,那么需要经分支管理员的评审并通过才能完成合并。

  • 合并的目标分支为非保护分支

发起者无需经过评审与授权,可以自行发起并完成分支合并。

关于如何修改默认分支与设置保护分支,详情请阅读分支设置

删除源分支

合并分支时,勾选删除源分支,可在合并分支时删除源分支。

Fast-Forward 模式合并

常规的分支合并时会默认产生一个合并提交记录。若勾选了 「Fast-Forward 模式合并」,远端仓库会在合并时判断是否符合 Fast-Forward 规则,若符合则此合并不会产生新的合并提交记录;若不勾选此模式,则会在合并时保留过往开发记录并产生一个新的合并记录。

此选项相当于使用 git merge 时添加 –ff 参数。

代码所有者

代码所有者机制需配合保护分支功能一起使用。在代码仓库中放置声明文件 CODEOWNERS 后,就可以声明此仓库内代码文件的所有者,通常为项目负责人。

当合并请求的目标分支为保护分支,且在请求中的改动文件涉及到声明文件中设定的路径或文件,合并请求详情中将列出对应的所有者与他们的评审状态。

如上图所示:CODEOWNER 文件内声明了 charts/repos/** 路径内文件的所有者是小白。若针对保护分支提交了合并请求且涉及到 chars/repos/ 路径下的文件变动将自动添加小白为此请求的评审者。

亦支持使用持续集成插件自动添加评审者,点击了解详情

在「保护分支」设置中勾选开启代码所有者评审后,管辖范围的代码变动需通过代码所有者的评审后方能合并。

声明文件地址

代码所有者的声明文件 CODEOWNERS 默认从以下位置逐层检索,文件名必须是大写格式,找到一个后就会停止搜寻。

  • 根目录
  • docs/ 目录

声明文件格式参考

声明文件是一个普通的文本文件,空行与 # 开始的行会被忽略,每行的格式为:

pattern email email email ...

pattern 指定了一个文件路径模式。email 为所有者邮箱,可以填写多个所有者,以空格分隔。

示例文件:

# 声明所有后缀名是 js 的文件
*.js yourname@coding.net

# 声明仓库根目录下 build/logs/ 目录内的文件(包括子目录)
/build/logs/ yourname@coding.net

# 声明所有 docs/ 文件夹内的文件(不包括子目录)
docs/* yourname@coding.net

# 声明所有根目录下 docs/ 文件夹内的文件(包括子目录)
/docs/ yourname@coding.net

上一篇cherry-pick
最近更新
感谢反馈有用
感谢反馈没用

在阅读中是否遇到以下问题?

您希望我们如何改进?