华为云用户手册

响应参数 状态码： 200 表4 响应Body参数 参数 参数类型 描述 offset Integer 起始偏移 limit Integer 查询大小 total Integer 总数 pipeline_runs Array of pipeline_runs objects 流水线运行信息 表5 pipeline_runs 参数 参数类型 描述 pipeline_id String 流水线ID pipeline_run_id String 流水线运行实例ID executor_id String 执行人ID executor_name String 执行人名称 stage_status_list Array of stage_status_list objects 阶段信息 status String 状态 run_number Integer 运行序号 trigger_type String 触发类型 build_params build_params object 构建参数 artifact_params artifact_params object 制品源参数 start_time Long 开始时间 end_time Long 结束时间 detail_url String 详情页地址 modify_url String 修改页地址 表6 stage_status_list 参数 参数类型 描述 name String 阶段名称 sequence Integer 序列号 status String 状态 start_time String 开始时间 end_time String 结束时间 id String 阶段ID 表7 build_params 参数 参数类型 描述 action String 合并请求事件类型 build_type String 基于分支还是tag触发 commit_id String 代码仓提交ID event_type String 运行事件类型 merge_id String 合并请求ID message String 代码仓提交信息 source_branch String 源分支 tag String 标签 target_branch String 目标分支 codehub_id String Repo代码仓ID git_url String 代码仓https地址 source_codehub_id String 源Repo代码仓ID source_codehub_url String 源Repo代码仓地址 source_codehub_http_url String 源Repo代码仓http地址 表8 artifact_params 参数 参数类型 描述 version String 包版本 branch_filter String 过滤分支 package_name String 包名称 organization String docker组织

请求参数 表2 请求Header参数 参数 是否必选 参数类型 描述 X-Auth-Token 是 String 用户Token。 通过调用 IAM 服务获取用户Token接口获取（响应消息头中X-Subject-Token的值）。 表3 请求Body参数 参数 是否必选 参数类型 描述 status 否 Array of strings 状态 start_time 否 String 开始时间 end_time 否 String 结束时间 offset 否 Long 起始偏移 limit 否 Long 查询大小 sort_key 否 String 排序字段名称 sort_dir 否 String 排序规则

新建提交规则 仓库管理员和仓库所有者可针对仓库某一分支新建提交规则，每个分支只能设置一条提交规则。 提交规则的优先匹配机制： 1、目标分支优先匹配已配置的提交规则； 2、精准匹配不到时，以模糊匹配到的第一条规则为准； 3、模糊匹配不到后以default规则为准。 表2 字段说明 字段 说明 规则名称 必填，新建提交规则的名称，限制200个字符。 分支规则 必填，下拉选择分支或者创建一个正则表达式，限制500个字符。 提交规则 非必填。 提交信息：提交信息默认为空，不会对提交信息校验，任何提交信息都可以提交，限制500个字符。 例如：设置Commit message的格式规则： TraceNo:(REQ[0-9]{1,9})(.|\n|.\n)Author:.*(.|\n|.\n)Description:.* 设置符合规范Commit message： TraceNo:REQ1234567 Author:**** Description:testpushfile 设置不符合规范Commit message： new files commit提交信息负面匹配规则：提交信息负面匹配规则默认为空，不会对提交信息校验，任何提交信息都可以提交，限制500个字符。 例如：设置Commit message的格式规则： TraceNo:(REQ[0-9]{1,9})(.|\n|.\n)Author:.*(.|\n|.\n)Description:.* 提交人：提交人默认为空，不会对提交人校验，任何人都可以提交，限制200个字符。 提交人可通过“git config -l”查看user.name的值，并通过“git config --global user.name”设置user.name的值。 例如： 设置提交人规则：([a-z][A-Z]{3})([0-9]{1,9}) 提交人邮箱地址：提交人邮箱地址默认为空，不会对提交人邮箱地址校验，任何邮箱地址都可以提交，限制200个字符。 提交人可通过“git config -l”查看user.email的值，并通过“git config --global user.email”设置邮箱。 例如： 设置提交人邮箱规则：@huawei.com$ 文件基本属性规则 非必填。 禁止提交的文件名称：禁止提交的文件名称规则默认为空，不会对文件名校验，任何文件都可以提交，建议正则编写时使用规范的正则语句进行匹配，文件名禁用规则处默认会根据规则校验文件所属路径，限制2000个字符。 例如： 设置禁止提交的文件名称规则：(\.jar|\.exe)$ 单文件大小限制(MB)：单文件推送大小（不含LFS）上限与您所购买的套餐规格一致，具体可查看约束与限制。 体验版/基础版：文件大小上限为200，表示添加或更新文件大小超过200MB，推送将被拒绝。管理员可以在0~200范围内修改值。 专业版/企业版：文件大小上限为300，表示添加或更新文件大小超过300MB，推送将被拒绝。管理员可以在0~300范围内修改值。 当用户变更套餐且配置的提交规则不变时，系统自动修改为当前套餐单文件大小限制。 二进制规则 非必填。 二进制规则默认不勾选，表示二进制文件默认可以上传【需满足单文件不超过上面设置的文件大小上限】。当“禁止新增二进制文件”被勾选时，“允许修改二进制文件”、“二进制文件白名单”、“特权用户”才生效。”允许修改二进制文件“勾选后，提交文件为modify状态的二进制文件不会拦截，可直接上传。二进制文件可以直接删除，不会进行二进制检查。 禁止新增二进制文件（对特权用户无效）。 允许修改二进制文件（对特权用户无效）。 二进制文件白名单（可直接入库的文件，限制2000个字符）。 特权用户（特权用户上限为50人）。 规则生效时间 非必填。 在生效日期之后创建的所有提交都必须与hook设置相匹配才能被推送。如果此字段为空，则无论提交日期如何，都将检查所有提交。 不推荐将二进制文件存放至代码托管仓库，会影响代码仓的性能和稳定性。 表3 常见正则表达式示例 规则 示例 单个a或b或c字符 [abc] 非a或b或c的字符 [^abc] 在a到z范围内的小写英语字母字符 [a-z] 在a到z范围外的字符 [^a-z] 在a到z或A到Z范围内的大小写英语字母字符 [a-zA-Z] 任意单个字符 . 选择 - 匹配 a 或 b a|b 任意空白字符 \s 非空白字符 \S 阿拉伯数字字符 \d 非阿拉伯数字字符 \D 字母、数字或下划线的字符 \w 非字母、数字或下划线的字符 \W 匹配括号中的内容（不捕获） (?:...) 匹配并捕获括号中的内容 (...) 零个或一个a a? 零个或更多a a* 一个及以上a a+ 三个a a{3} 三个a以上 a{3,} 3到6个a a{3,6} 文本开头 ^ 文本末尾 $ 单词边界 \b 非单词边界 \B 换行符 \n 回车符 \r 制表符 \t 空字符 \0

使用SSH协议在Git Bash客户端克隆代码 本节内容描述如何使用Git Bash客户端克隆 代码托管服务 的仓库到本地环境中。 下载并安装Git Bash客户端。 设置SSH密钥。 获取仓库地址。（没有仓库？如何新建仓库？） 在仓库主页中，单击“克隆/下载”按钮，获取SSH地址，通过这个地址，可以在本地计算机连接代码托管仓库。 如果您未配置SSH密钥，你可单击上图中“SSH密钥管理”链接进行配置，详情请参考SSH密钥。 您可在代码托管服务仓库列表中“仓库地址”下获取SSH地址。 打开Git Bash客户端。 在本地计算机上新建一个文件夹用于存放代码仓库，在空白处单击鼠标右键，打开Git Bash客户端。 克隆仓库时会自动初始化，无需执行init命令。 输入如下命令，克隆代码托管仓库。 git clone 仓库地址 命令中“仓库地址”即3中获取的SSH地址。 如果您是第一次克隆仓库，会询问您是否信任远程仓库，输入“yes”即可。 执行成功后，您会看到多出一个与您在代码托管服务新建的仓库同名的文件夹，并且其中有一个隐藏的.git文件夹，则说明克隆仓库成功。 此时您位于仓库上层目录，执行如下命令，进入仓库目录。 cd 仓库名称 进入仓库目录，可以看到此时Git默认为您定位到master分支。 客户端在git clone代码仓库时失败的原因排查： 确保您的网络可以访问代码托管服务。 请在git客户端使用如下测试命令验证网络连通性。 ssh -vT git@**********.com 如果返回内容含有“Could not resolve hostname **********.com: Name or service not known”，则您的网络被限制，无法访问代码托管服务，请求助您本地所属网络管理员。 请检查建立的SSH密钥配对关系，必要时重新生成密钥并到代码托管控制台进行配置。 只有开启IP白名单的机器才可以在Git客户端克隆。

使用SSH协议在TortoiseGit客户端克隆代码 本节内容描述如何使用TortoiseGit客户端克隆代码托管服务的仓库到本地环境中。 下载并安装TortoiseGit客户端。 获取仓库地址。（没有仓库？如何新建仓库？） 在仓库主页中，单击“克隆/下载”按钮，获取SSH地址，通过这个地址，可以在本地计算机连接代码托管仓库。 您可在代码托管服务仓库列表中“仓库地址”下获取SSH地址。 进入您的本地仓库目录下，右键选择“Git克隆”菜单选项，如下图所示。 在弹出的窗口中将上述复制的SSH地址粘贴到URL输入框中，勾选“加载Putty密钥”并选择私钥文件，最后单击“确定”，如下图所示。 单击“确定”之后即开始克隆仓库，如果您是第一次克隆TortoiseGit客户端会询问您是否信任远程仓库，单击“是”即可。 克隆用时受仓库大小影响，克隆的动作如下图所示。

查看仓库详情 在仓库列表中单击仓库名称可进入该仓库的详情页面，代码托管服务提供了丰富的控制台操作，详情如下。 表1 页签说明 功能页签 功能说明 仓库首页 用于展示仓库的容量、提交次数、分支数量、标签数量、成员数量、LFS使用量、创建时间、创建者、可见范围、仓库状态、readme文件、语言、语言占比等信息。 代码 文件列表：支持新建文件、新建目录、新建子模块、上传文件、在线修改文件、修改追溯和查看提交历史等操作。 提交：支持查看提交记录及仓库网络图。 分支：支持在控制台管理分支。 Tags：支持在控制台管理标签。 对比：支持通过对比查看分支之间或标签版本之间发生的代码变化。 合并请求 支持在控制台管理分支的合并请求。 评审记录 支持查看合并请求的评审记录与Commit的评审记录。 关联工作项 所关联工作项的列表，其可设置与需求管理中工作项的联动，提升效率。 仓库统计 仓库提交记录的可视化图表，主要展现了代码贡献度等信息。 动态 支持查看仓库动态信息。 成员 仓库成员管理页面，支持一键从项目同步成员，也可以单独调整某个成员的权限。 设置 此仓库的设置入口，只有仓库管理员和仓库创建者可以看到此页签并进行设置。 另外仓库详情页框架上还提供以下功能的快捷入口： 设置构建：新建编译构建任务入口。 IDE Online：可使用IDE Online打开代码（目前 免费体验 ，仅支持北京一、北京四及大连局点）。 关注：单击可关注该仓库，关注的仓库会在仓库列表置顶。 Fork：会显示目前仓库有几个Fork出的仓库，单击弹出新建-Fork页面。 克隆/下载：可获取仓库的SSH地址、HTTPS地址，也可以直接下载代码压缩包。 代码托管“吸顶”功能，当用户的仓库界面长度大于窗口长度，向下滑动鼠标滚轮后，仓库页签置顶，下图中红框位置被折叠，便于查看仓库信息，向上滑动鼠标滚轮后，界面恢复。 父主题： 使用代码托管仓库

如何使用标签找回历史版本 当您要查看某个标签指向版本的代码时，可以将其检出到工作区。由于被检出的版本仅隶属于标签，而不属于任何分支，因此该代码可以编辑，但是不能add、commit。您可以基于工作区新建一条分支，在此分支上修改代码，并将此分支合入主干。具体的操作步骤如下所示。 通过标签检出历史版本。 git checkout V2.0.0 #将被标签为 V2.0.0 的版本检出到工作区 基于当前的工作区新建一条分支并切换到其中。 git switch -c forFixV2.0.0 #新建一条名为 forFixV2.0.0 的分支，并切换到其中 （可选）如果修改了新建的分支的内容，需要将修改内容提交到该分支的版本库中。 git add . #将修改添加到新分支的暂存区 git commit -m "fix bug for V2.0.0" #将修改内容存入该分支的版本库 切换到master分支，并将新建立的分支合入（本示例中为 forFixV2.0.0 分支）。 git checkout master #切换到master分支 git merge forFixV2.0.0 #将基于历史版本的修改 合入到master分支 以上命令旨在帮助您理解通过标签找回历史版本的过程原理，请根据原理自行裁剪增补Git命令以完成您在特定场景下需要的操作，不建议全流程直接复制使用。

在控制台管理标签 在控制台的标签列表中，可查看该远程仓库中的全量标签并进行如下操作。 单击“标签名”，跳转到该标签对应版本的文件列表。 单击“提交号”，跳转到该次提交（commit）的详情页面。 单击，可下载tar.gz或zip格式的被标签版本的文件包。 单击，可以将此标签从代码托管仓库删除（想从本地删除请clone、pull或本地手动-d删除）。 若仓库设置IP白名单，则只有IP白名单内的机器才可以在界面下载仓库源码，若仓库没有设置IP白名单，则均可在界面下载仓库源码。 在控制台创建分支时，您可以选择基于某个标签去创建分支。 在控制台中，单击“代码”页签，单击目标文件的“文件名称”，单击文件的“对比”页签，可在该文件的提交记录之间做差异对比。

Webhook简介 开发人员可在 Webhook 界面配置第三方系统的 URL，并根据项目需求订阅代码托管仓库的分支推送(push)、标签推送(tag push)等事件。当订阅事件发生时，可通过Webhook向第三方系统的URL发送 POST请求，用以触发自己系统（第三方系统）的相关操作，例如：触发自己系统（第三方系统）界面的通知弹窗；或触发自己系统（第三方系统）的构建、更新镜像、部署等操作。 若您需要用发送邮件作为仓库变化的通知方式，可通过配置“基本设置”中的“通知设置”实现。

基于Git分支的经典工作模式 在基于分支的代码管理工作模式中，“Git-Flow”在业界被更多人认可，同时也被广泛应用，如果您的团队目前还没有更好的工作模式，可以先从尝试使用“Git-Flow”开始。 Git-Flow是一种基于Git的代码管理工作模式，它提供了一组分支使用建议，可以帮助团队提高效率、减少代码冲突，其具备以下特性。 并行开发：支持多个特性与bug修复并行开发，因其可以同时在不同分支中进行，所以在代码写作时互不受影响。 团队协作：多人开发过程中，每条分支（可以理解为每个子团队）的开发内容可以被单独记录、合并到项目版本中，当出现问题时还可被精确检出并单独修改而不影响主版本的其它代码。 灵活调整：通过HotFix分支的使用，支持各种紧急修复的情况，而不会对主版本以及各个团队的子项目产生干扰影响。 表1 Git-Flow工作模式中分支的使用建议 分支名 Master Develop Feature_1\2... Release HotFix_1\2... 说明 核心分支，配合标签，用于归档历史版本，要保证其中的版本都是可用的。 开发主分支，用于平时开发的主分支，应永远是功能最新最全的分支。 新特性开发分支，用于开发某个新特性，可以几条并行存在，每条对应一个或一组新特性。 发布分支，用于检出某个要发布的版本。 快速修复分支，用于当现网版本发现bug时，拉出来单独用于修复这些bug的分支。 有效性 长期存在 长期存在 临时 长期存在 临时 何时被创建 项目仓库建立之初 在master分支被创建之后 收到新特性任务时，基于develop分支创建 当正在开发的新特性任务被拆分成出子任务时，基于对应的父feature分支创建 项目首次发布前，基于develop分支创建 当master、bug版本中发现问题时，基于对应版本（一般是master分支）创建 何时直接在此分支上开发 从不 一般不建议 当被创建出来，开始开发新特性时 从不 当被建立出来时 何时被其它分支合入 项目版本封版时，被develop或release分支合入 已发布版本中发现的bug被修复后，被对应的hotfix分支合入 新特性开发完成后，feature分支合入到此分支 当项目启动开发一个新版本时，被上一次历史发布版本（release、或master）合入 子feature分支开发、测试完成后，会合入到父feature分支 当需要发布一个版本时，被develop分支合入 - 何时合入到其它分支 - 当要发布版本时，合入到release分支 当需要归档版本时合入到master分支 当该分支上的新特性开发、测试完成时，合入到develop分支 当完成一次版本发布，将该版本归档时，合入到master分支 当要基于某一个发布版本，开始开发一个新版本时，合入到develop分支，起到初始化版本的作用 当其对应的bug修复任务完成时，会将其作为修复补丁合入master、develop分支 何时结束生命周期 - - 其对应的特性已经验收(发布、稳定)后 - 其对应的bug修复，已经验收(发布、稳定)后 另外在使用Git-Flow工作模式时，业界普遍遵循如下规则： 所有开发分支从develop分支拉取。 所有hotfix分支从master分支拉取。 所有在master分支上的提交都必须要有标签，方便回滚。 只要有合并到master分支的操作，都需要和develop分支合并，保证同步。 master分支和develop分支是主要分支，并且都是唯一的，其它派生分支每个类型可以同时存在多个。

在控制台中管理分支 在控制台的分支列表中可以进行如下操作。 分支筛选 我的分支：显示我创建的所有分支，按最近提交时间排序，最新提交的分支将更靠前。 活跃分支：显示过去三个月内存在开发活动的分支，按最近提交时间排序，最新提交的分支将更靠前。 过时分支：显示过去三个月内没有任何活动的分支，按最近提交时间排序，最新提交的分支将更靠前。 所有分支：显示所有分支，“默认分支”将显示在最前面，其余分支按最近提交时间排序，最新提交的分支将更靠前。 单击某个“分支名称”，可跳转到该分支的文件列表，可查看该分支的内容、历史等信息。 单击某个分支的提交ID，可跳转到该分支的最新一次提交记录详情中，可查看本次提交的内容。 单击分支名称前面的勾选框，单击“批量删除”，可批量删除分支。 单击某个，可对该分支进行工作项关联操作。 单击某个，可定位到“对比”子页签，可以对将此分支与其它分支进行差异对比。 单击某个，可下载该分支的压缩包到本地。 单击某个，可以跳转到“合并请求”页签，可对该分支创建分支合并请求。 单击某个，可跳转到仓库设置中设置该分支为保护分支。 单击某个，可以按提示操作，将该分支进行删除。 只有开启IP白名单的机器才可以从界面下载源码压缩包。 如果您误删了分支，可提交工单联系技术支持处理。 另外在控制台中您还可以对分支进行相关的设置： 合并请求设置 默认分支管理 分支保护设置

IP白名单格式 IP白名单支持IPv4和IPv6，有3种格式，如下表所示。 表1 IP白名单格式 格式 说明 单个IP 这是最简单的一种IP白名单格式，如将您的个人家庭电脑的IP添加到白名单中，比如：100.*.*.123。 IP范围 当您拥有不止一台服务器而且IP段是连续的，或者您的IP会在一个网段内动态变化，这时您可以添加一个IP白名单范围，比如：100.*.*.0 - 100.*.*.255。 CIDR格式（无类别域间路由） 当您的服务器在一个局域网内并使用CIDR路由时，您可以指定局域网的32位出口IP以及一个指定网络前缀的位数。 从同一个IP发起的请求，只要网络前缀同您设定的前缀部分相同，即可视为来自同一授信范围从而被接受。

迁移方法二：HTTP在线导入 首先确保你的SVN服务器支持HTTP或HTTPS方式访问，可以在任一浏览器，输入“http(s)://SVN服务器地址/访问仓库名称”进行验证。 在代码托管仓库列表页，单击“普通新建”旁的，在下拉列表中选择“导入外部仓库”。 源仓库路径填入要导入的SVN仓库地址，输入相应SVN用户名、密码，勾选“我已阅读并同意《隐私政策声明》和《软件开发服务使用声明》”，单击“下一步”。 输入要新建的代码仓库名称，进行相应权限配置，单击“确定”，等待仓库创建。 代码仓库创建成功后，单击仓库名称查看仓库详情。

如何将Fork仓库中的修改合入源仓库 进入代码托管服务仓库列表页。 单击Fork仓库名称，进入Fork仓库。 单击“合并请求”，切换到合并请求页签。 单击“新建”，弹出“新建合并请求”页面。 “源分支”为本仓库作为请求合并的分支。 “目标分支”为该仓库的源仓库被合入的分支。 单击“下一步”，进入到新建合并请求页面，其后面的操作流程与仓库内部的新建合并请求完全一致，请参考新建合并请求。 跨仓库的合并请求隶属于源仓库，只能在源仓库的“合并请求”页签中看到，在Fork仓库（请求发起方仓库）中看不到，因此选择的检视人、评审人、审核人及合并人均为源仓库的人员。

Fork仓库与导入外部仓库的区别 Fork仓库与导入外部仓库的本质都是仓库的复制，其主要区别在于操作后源仓库与复制出仓库的联动关系不同，详细如下： Fork仓库 Fork仅应用于代码托管平台内的仓库间复制。 Fork仓库时，会基于源仓库的当前版本复制出一个内容相同的副本仓库，您在副本仓库的修改，可以申请合并（可以理解为一种跨仓库的分支合并）回源仓库，但副本仓库不能再获取源仓库的更新。 导入外部仓库 导入外部仓库不仅可以将其它版本管理平台的仓库进行导入（主要针对基于Git、SVN存储的托管平台），也可以导入代码托管服务自己的仓库。 导入外部仓库时，也会基于源仓库的当前版本复制出一个内容相同的副本仓库，所不同的是，副本仓库不能向源仓库提交合并申请，但是副本仓库可以随时拉取源仓库的默认分支，以起到获取最新版本的作用。

从浏览器下载代码包 除了克隆以外，代码托管服务同时支持将仓库代码打包下载到本地。 使用直接下载方式获取的代码仓库文件与代码托管仓库没有关联关系，不能将内容回推代码托管仓库。 其操作步骤如下： 进入代码托管服务仓库列表页。 进入您的仓库。（如何新建仓库？） 单击“克隆/下载”按钮，在弹出的窗口中单击需要的代码包类型即可直接在浏览器中下载。 若仓库设置IP白名单，则只有IP白名单内的机器才可以在界面下载仓库源码，若仓库没有设置IP白名单，则均可在界面下载仓库源码。 目前支持的下载包格式有：zip、tar.gz、tar.bz2、tar。 下载的代码包是对应的代码托管仓库的master分支内容。 父主题： 克隆/下载代码托管仓库到本地

操作步骤 在代码托管服务中，创建一个空仓库。 不选择“选择gitignore”。 不勾选“允许生成README文件”。 在本地，准备好将要上传的源代码。 如果原来是来自SVN服务器的，建议参考将SVN代码库迁移到Git代码库。 如果原来没有纳入过任何的版本系统，则在源代码的根目录，执行以下git命令（以Git Bash为例）： 初始化Git仓库： git init 将文件加入版本库： git add * 创建初始提交： git commit -m "init commit" 设置本地仓库的远程服务器地址： 如果原来从其它地方clone的git仓库，则添加一个新的remote，命令行参考如下： git remote add new git@***.***.com:testtransfer/Repo1.git #（new 后面为仓库地址） 仓库地址在仓库详情页，获取方式如下图： 如果是一个刚刚初始化的仓库，则添加一个名为origin的remote，命令行参考如下： git remote add origin git@***.***.com:testtransfer/Repo1.git #（origin 后面为仓库地址） 推送全部代码到代码托管仓库： git push new master #（对应步骤3的第一种情况） git push origin master #（对应步骤3的第二种情况） 以上操作需要一定的Git基础知识，如遇到问题可以在Git官网学习或者申请技术支持。

对合并请求进行检视、审核与合入 当检视人、审核人、合并人收到系统的分支合并请求通知邮件时，请按以下步骤进行操作。 进入目标仓库详情页。 切换到“合并请求”页签，单击目标合并请求名称，查看详情。 对目标合并请求进行检视。 检视人与审核人均可对合并请求进行检视并给予检视意见，若无修改意见，检视人可单击“检视通过”完成检视。 对目标合并请求进行审核。 审核人可通过单击“拒绝”或“通过”对合并请求进行审核。 通过合并请求门禁。 表2 合入条件说明 合入条件 说明 代码合并冲突 当源分支代码与目标分支代码产生合并冲突时，需要先解决冲突才可进行下一步操作，解决代码冲突可参考解决合并请求的代码冲突。 评审意见门禁 当发起人解决所有检视人或审核人的评审意见后，门禁显示通过，更多门禁详情请参考评审意见门禁详解。 流水线门禁 当最新commit或者预合并commit拉起并成功执行流水线时，门禁显示通过，更多门禁详情请参考流水线门禁详解。 E2E单号未关联 当合并请求关联工作项后，门禁显示通过，更多门禁详情请参考E2E单号关联门禁详解。 星级评价未通过 当指定人员进行星级评价后，门禁显示通过，更多门禁详情请参考星级评价门禁详解。 检视门禁 当已检视的检视人数达到最小检视人数时，门禁显示通过，更多门禁详情请参考检视门禁详解。 审核门禁 当已审核的审核人数达到最小审核人数时，门禁显示通过，更多门禁详情请参考审核门禁详解。 对目标合并请求进行合入。 当发起人通过以上合入条件后，合并人可单击“合入”按钮进行合入，反之，合并人可单击“关闭”将请求关闭。

新建合并请求 假设管理员已经设置好了分支合并规则，当您在开发分支上完成了功能开发，并需要发起合并请求时，请按照以下流程操作。 进入目标仓库详情页。 切换到“合并请求”页签。 单击“新建”按钮，选择要合并的分支。 如上图在本示例中将刚完成开发任务的Dev分支合并到master分支中。 支持源分支选择Fork仓库的分支。 单击“下一步”按钮，此时系统会检测两条分支是否有差异。 如果分支没有差异，系统会做出提示，且不能新建合并请求。 如果分支存在差异，则进入如下“新建合并请求”页面。 在“新建合并请求”页面的下方可以看到两条分支的文件差异对比详情、要合并分支的提交记录。 根据下表参数说明，填写页面信息。 表1 参数说明 参数 说明 更改分支 单击可返回上一步更改需要合并的分支。 模板 若仓库管理员或所有者已为该仓库创建合并请求模板，您可以直接选择使用模板。 说明： 该功能仅支持“专业版套餐”及“铂金版套餐”用户。 标题 输入合并请求的标题。 描述 会结合分支合并情况与要合并分支的提交（commit）备注生成默认值，您可以根据项目情况进行修改。 关联工作项 可选择将合并动作关联到某个工作项，以起到自动改变工作项状态的作用。 合并人 在合并请求满足合入要求时，一般是所有审核人审核通过、所有问题都被解决（可设置不解决也能合并），合并人有权限执行合并操作（单击按钮）、也有权限关闭合并请求。 检视人 被指定参与合并分支检视，可以提出问题给发起人。 评审人 被指定参与合并分支评审，可以给出审核意见（审核通过、拒绝），也可以提出问题给发起人。 合并后删除源分支 可选择是否合并后删除源分支，初始会带入合并请求设置中预设状态。 Squash合并 开启Squash合并，可使基本分支的历史记录保持干净，并带有有意义的提交消息，而且在必要时可以更简单地恢复，详情请参考Squash合并。 单击“新建合并请求”按钮，可以完成合并请求的提交，页面会跳转到该“合并请求详情页”。 在合并请求详情中，可以看到合入条件达成的状态、合并人、检视人、审核人、所关联的工作项等信息，同时可以查看可留下评审意见，可标注评审意见为待解决状态，并可看到该合并涉及的所有动态。 “提交记录”：可以看到源分支的相关提交记录。 “文件变更”：可以看到此次合并的变更内容，并可具体筛选出新增、修改、删除、重命名等变更种类。 “流水线”：可以看到门禁流水线的信息。 当发起分支合并请求时，其相关人员（审核人、合并人）会收到提醒邮件。审核人不能为合并请求创建者。 单个文件差异超过5000行、差异文件个数超过100个时，建议使用客户端合并后，推送到代码托管。

合并请求列表 在仓库详情的“合并请求”页签中，可以看到“合并请求列表”页面。 可以切换、查看不同状态的合并请求。 通过单击请求标题可以进入合并请求详情页。 可以查看请求的简要信息，包括：涉及的分支、创建时间、创建人。 提供了多条件维度的查找功能。 在左上方有新建合并请求入口。 开启中：代表该请求已进入检视或合并阶段，分支未合并。 已合并：代表该请求已经完成审核，并完成分支合并的动作。 已关闭：代表该请求被取消，分支未产生实际合并。 所有：显示所有状态的合并请求。

自动提取单号规则 自动提取单号规则（根据代码提交信息自动提取单号），配置规则具体如下： 单号前缀：非必填项，支持多个前缀，最多10个，如“【问题单号or需求单号】”。 若单号前缀、分隔符、单号后缀规则不为空，则默认开启自动单号提取功能 分隔符：非必填项，默认为“；”。 单号后缀：非必填项，默认为换行符。 前缀、分隔符、后缀不能相同。 分隔符为空时，前缀和后缀不能为“；；”。 后缀为空时，前缀和分隔符不能为\n。 前缀、分隔符、后缀为全字符匹配，不支持正则表达式。

操作步骤 一般情况下，开发者不会直接在master分支中进行开发，而是基于master或者dev分支创建一条feature分支，在feature中进行开发，然后将其推送到代码托管仓库，最后在代码托管仓库中将其合并到master或dev分支中，下面将模拟以上操作。 进入本地仓库目录，打开Git客户端，本案例以Git Bash为例，其它使用Git进行管理的工具的原理和命令使用基本是一致的。 基于master分支新建一条分支feature1001，并切换到其中，在master分支中执行以下命令。 git checkout -b feature1001 #如下图① 这个命令相当于先新建分支，然后直接切换到此分支。 执行成功如下图中②所示，此时可用ls命令查看其中包含的文件(如下图中③)，此时他与master分支中内容是一样的。 在feature分支中进行修改（代码开发）。 Git支持Linux命令，本案例用touch命令新建一个newFeature1001.html文件，代表开发者已经在本地完成了新特性的开发，其对本地代码库的影响是新增了文件。 touch newFeature1001.html 创建后再次使用ls命令可以看到多出了这个文件。 使用add、commit命令依次将文件从工作区加入暂存区，再提交到本地版本库。（这是什么原理？） 期间可以穿插使用status命令，观察文件状态。 使用status命令看到，目前工作区有一个文件未纳入版本管理，如图中①。 使用add命令将文件加入暂存区，如图中②。 git add . #使用“.”代表所有文件，包括隐藏的，也可以直接指定某个文件 使用status命令看到，文件已经加入到暂存区，正在等待提交，如图中③。 使用commit命令将文件提交到本地版本库，如图中④。 git commit -m “您的提交备注” 再次查看状态，没有可处置文件，说明提交成功了，如图中⑤。 将本地的分支推送到代码托管仓库。 git push --set-upstream origin feature1001 本命令会在代码托管仓库新建一条与您本地feature1001一样的分支，并将其进行关联、同步。 其中origin是您的代码托管仓库名称，一般直接可控的仓库默认别名为origin，您也可以直接用仓库地址代替。 如果推送失败请检查连通性： 确保您的网络可以访问代码托管服务。 请在git客户端使用如下测试命令验证网络连通性。 1 ssh -vT git@********.com 如果返回内容含有“connect to host ********.com port 22: Connection timed out”，则您的网络被限制，无法访问代码托管服务，请求助您本地所属网络管理员。 请检查建立的SSH密钥配对关系，必要时重新生成密钥并到代码托管控制台进行配置，请参考SSH密钥或确认HTTPS密码正确配置。 检查IP白名单。注意，在未配置白名单时，全部IP均会放行，如果配置了则只允许名单内的IP访问。 查看代码托管仓库分支。 登录代码托管服务，进入您的仓库，在文件列中可以看到此时已经可以在代码托管仓库切换到您的分支。 如果没有看到您刚推送上来的分支，很可能是您的origin绑定到了另外的仓库，请使用仓库地址再次推送。 此时您可以使用代码托管服务提供的合并请求管理功能，发起分支合并，并通知审核人进行评审，最终将新特性合入到master或dev分支中。

在代码托管控制台提交代码并关联工作项 进入仓库详情页。 新建一个文件，如下图所示，在填写“提交信息”时以fix #708206209开头，其他信息任意即可。 708206209是task02的编号。 单击“确定”按钮，此时系统相当于在代码托管仓库上执行了以下操作： 新建文件写入内容 git add . git commit -m "fix #708206209 Task02" 也就是将一个新建的文件进行了一次commit，并通过-m参数中的“fix”关键字关联到了task02工作项。 验证。 此时您再去查看task02工作项时，如下图所示： 其状态已经置于“已解决”。 增加了一条关联得代码提交记录，单击提交编号可以前往查看提交详情。 增加了一条自动生成的评论以说明本次工作项关联。

在本地提交代码并关联工作项 首先您需要在本地具备Git环境，详细请参考Git客户端安装与配置，在可以访问仓库时（已经关联到了对应的远程仓库），可以开始进行以下操作。 在本地的master分支上新建一个文件，将其推送到远程仓库，在推送时-m里使用“fix”关键字去关联工作项task01。 本示例直接修改master分支，是为了缩短流程减少杂音让开发者更快的了解本地提交关联工作项的操作和原理。 在实际代码开发中，尽量不要直接修改master分支，推荐新建一个分支进行文件操作，操作完后再合并到master分支并将master推送到远程仓库。（这是一种默认规则和良好习惯） 在本地仓库文件夹下单击鼠标右键，打开Git Bash客户端。 确认远程仓库地址绑定是否成功。 git remote -v #该命令可以查看目前本地仓库所绑定的远程仓库地址。 如下图返回内容中，红线部分是本地仓所关联的远程仓库地址，地址之前是远程仓库在本地的别名。 如果发现绑定的仓库并非需要关联的仓库，或者没有绑定仓库，推荐直接将想绑定的仓库Clone到本地。 Clone成功以后再次执行“git remote -v”查看确认绑定正确即可。 （上步骤已Clone的仓库可跨过此步）用status命令查看下目前仓库的状态，切换到master分支。 git status #查看当前仓库状态，可以看到目前处于哪个分支、该分支有没有未暂存、未提交、未推送的修改 git checkout master #切换到master分支，如果当前没有处于master分支时使用 在本地仓库文件夹下新建一个文件，本示例中将其命名为“fileFor708206208”。 在Git Bash中将新建的文件添加到暂存区。 git add fileFor708206208 在Git Bash中将本次操作提交。 git commit -m "fix #708206208 Task01" #/本次提交用fix关键字关联了编号为708206208的task01 708206208是task01的编号。 在Git Bash将提交的内容推送到关联的代码托管仓库。 git push 如下图为推送成功，不同仓库结构返回会略有不同，只要看到所有步骤都100%、done就是推送成功了，如果推送失败一般是您的密钥问题。 验证关联结果。 上述操作完成后，进入工作项列表，找到编号为708206208的工作项，进入查看详情，如下图所示： 其状态已经置于“已解决”。 增加了一条关联得代码提交记录，单击提交编号可以前往查看提交详情。 增加了一条自动生成得评论以说明本次工作项关联。

IAM用户、项目成员与仓库成员的关系 仓库成员来源于其所属项目的项目成员，项目成员主要来源于租户的IAM用户，除项目创建者所在租户外，还可以邀请其它租户下的IAM账号加入项目。如下图为IAM用户、项目成员、仓库成员的包含关系示意图。 表1 项目角色与仓库角色对应关系 项目中的角色 仓库中的角色 项目经理 管理员 开发人员 开发者 测试经理 浏览者 测试人员 参与者 浏览者 运维经理 自定义角色 可由项目创建者设置为Commiter、开发者或浏览者 项目产生的费用将计算在项目经理所属的租户下。 父主题： 管理仓库成员

安装Git LFS 不同操作系统的安装方法如下表所示。 表1 Git LFS安装方法 操作系统 安装方法 Windows 安装不低于Git 1.8.5版的Git客户端，然后在命令行中执行： git lfs install Linux 根据自己的操作系统和cpu架构在PackageCloud网站下载对应的安装包。 先解压安装包，再执行install.sh脚本进行安装，然后执行如下命令检查是否安装成功： git lfs version macOS 首先安装Homebrew软件包管理工具，然后在命令行中执行： $ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" $ brew install git-lfs $ git lfs install

配置追踪文件 配置追踪文件方法如下所示。 表2 追踪文件配置方法 场景 方法 追踪所有后缀名为“.psd”的文件 追踪所有后缀名为“.psd”的文件： git lfs track "*.psd" 追踪单个文件 追踪单个文件： git lfs track "logo.png" 查看已追踪的文件 查看已追踪的文件，可以通过git lfs track，或通过查看“.gitattributes”文件，获取详情： $ git lfs track Listing tracked patterns *.png (.gitattributes) *.pptx (.gitattributes) $ cat .gitattributes *.png filter=lfs diff=lfs merge=lfs -text *.pptx filter=lfs diff=lfs merge=lfs -text

背景信息 代码托管支持Git LFS（Large File Storage，大文件存储）协议，可以把音乐、图片、视频等指定的任意大文件资源存储在Git仓库之外，对于使用者而言，类似在操作一个完整的Git仓库，非常方便。通过将大文件存储在Git原有的数据结构之中，可以减小Git仓库本身的体积，使克隆Git仓库的速度加快，也使得Git不会因为仓库中充满大文件而损失性能。 当您要上传的文件单个超过200MB时，需要使用Git LFS。 使用操作包含以下内容： 安装Git LFS 配置追踪文件 提交大文件 克隆包含Git LFS文件的远程仓库 更多操作

请求示例 https://{endpoint}/v5/d80a8a6530324b7bac972cbb8a9f28ec/pipelines/e2bcbd561fbc4fd89577fb27c80b09a6/pipeline-runs/9e91b1fd7ce743b7a1b7a2458bcf76c7/jobs/6ce8600f396c4d5ba5290201ba9fd762/steps/7a1a7bb1b5e74d1c944d8b8971621033/logs { "start_offset" : 0, "end_offset" : 0, "limit" : 500, "sort" : "asc" }

响应示例 状态码： 200 查询日志响应体 { "has_more" : false, "end_offset" : "25705", "start_offset" : "6132", "log" : "[2023/11/24 21:49:32.198 GMT+08:00] [INFO] [real_stage:执行Shell] : 该步骤开始执行。\n[2023/11/24 21:49:32.201 GMT+08:00] [INFO] [real_stage:执行Shell] : ================== start to do VmExecutionStep ==================\n[2023/11/24 21:49:32.207 GMT+08:00] [INFO] [real_stage:执行Shell] : [frame] start to send status data to service.\n[2023/11/24 21:49:32.225 GMT+08:00] [INFO] [real_stage:执行Shell] : [frame] finish to save status data to service.\n[2023/11/24 21:49:32.777 GMT+08:00] [INFO] [real_stage:执行Shell] : slave arch: amd64\n[2023/11/24 21:49:33.330 GMT+08:00] [INFO] [real_stage:执行Shell] : download file result: SUC CES S\n[2023/11/24 21:49:36.547 GMT+08:00] [2023-11-24 21:49:36] [INFO] =========== flow agent launched in [octopus_container] ===========\n[2023/11/24 21:49:36.548 GMT+08:00] [2023-11-24 21:49:36] [INFO] =========== use env job loader ===========\n[2023/11/24 21:49:36.548 GMT+08:00] [2023-11-24 21:49:36] [INFO] start to do status callback\n[2023/11/24 21:49:36.548 GMT+08:00] [2023-11-24 21:49:36] [INFO] successfully callback to flow service\n[2023/11/24 21:49:36.548 GMT+08:00] [2023-11-24 21:49:36] [INFO] step begin: [1/1]-[执行Shell]\n[2023/11/24 21:49:36.548 GMT+08:00] [2023-11-24 21:49:36] [INFO] start to use official executor [official_shell_plugin]\n[2023/11/24 21:49:36.548 GMT+08:00] [2023-11-24 21:49:36] [INFO] ###############################@@@ 【step start】 @@@###############################\n[2023/11/24 21:49:36.548 GMT+08:00] [2023-11-24 21:49:36] [INFO] =========== start to use script executor ===========\n[2023/11/24 21:49:36.548 GMT+08:00] [2023-11-24 21:49:36] [INFO] =========== start to execute shell pre function [make temp dir] ===========\n[2023/11/24 21:49:36.548 GMT+08:00] [2023-11-24 21:49:36] [INFO] =========== shell pre function [make temp dir] current temp dir:[/data/workspace/6ce8600f396c4d5ba5290201ba9fd762/7a1a7bb1b5e74d1c944d8b8971621033] ===========\n[2023/11/24 21:49:36.548 GMT+08:00] [2023-11-24 21:49:36] [INFO] =========== end to execute shell pre function [make temp dir] successfully ===========\n[2023/11/24 21:49:36.548 GMT+08:00] [2023-11-24 21:49:36] [INFO] =========== start to execute custom shell ===========\n[2023/11/24 21:49:36.548 GMT+08:00] [2023-11-24 21:49:36] [INFO] 1\n[2023/11/24 21:49:36.548 GMT+08:00] [2023-11-24 21:49:36] [INFO] =========== finish to use script executor with status success ===========\n[2023/11/24 21:49:36.548 GMT+08:00] [2023-11-24 21:49:36] [INFO] ################################@@@ 【step end】 @@@################################\n[2023/11/24 21:49:36.548 GMT+08:00] [2023-11-24 21:49:36] [INFO] finish to use official executor\n[2023/11/24 21:49:36.548 GMT+08:00] [2023-11-24 21:49:36] [INFO] step 执行Shell succeed. \n[2023/11/24 21:49:36.548 GMT+08:00] [2023-11-24 21:49:36] [INFO] start to do data callback with context:[{1eaa92ecea2a42cab78e5269963a48c1 6ce8600f396c4d5ba5290201ba9fd762 7a1a7bb1b5e74d1c944d8b8971621033 0}]\n[2023/11/24 21:49:36.548 GMT+08:00] [2023-11-24 21:49:36] [INFO] successfully callback to flow service\n[2023/11/24 21:49:36.548 GMT+08:00] [2023-11-24 21:49:36] [INFO] current step, duration time: [0.030766842]\n[2023/11/24 21:49:36.548 GMT+08:00] [2023-11-24 21:49:36] [INFO] start to do status callback\n[2023/11/24 21:49:36.548 GMT+08:00] [2023-11-24 21:49:36] [INFO] successfully callback to flow service\n[2023/11/24 21:49:36.548 GMT+08:00] [2023-11-24 21:49:36] [INFO] =========== flow agent end ===========\n[2023/11/24 21:49:36.563 GMT+08:00] [INFO] [real_stage:执行Shell] : [frame] start to send status data to service.\n[2023/11/24 21:49:36.563 GMT+08:00] [INFO] [real_stage:执行Shell] : 该步骤执行完成。", "location" : "jenkins", "step_run_id" : "7a1a7bb1b5e74d1c944d8b8971621033" }