华为云用户手册

  • 响应参数 状态码: 200 表4 响应Body参数 参数 参数类型 描述 result String 响应状态 状态码: 400 表5 响应Body参数 参数 参数类型 描述 error Object 错误信息返回体。 表6 ErrorDetail 参数 参数类型 描述 error_code String 错误请求返回的错误码。 error_msg String 错误请求返回的错误信息。 状态码: 403 表7 响应Body参数 参数 参数类型 描述 error Object 错误信息返回体。 表8 ErrorDetail 参数 参数类型 描述 error_code String 错误请求返回的错误码。 error_msg String 错误请求返回的错误信息。 状态码: 500 表9 响应Body参数 参数 参数类型 描述 error Object 错误信息返回体。 表10 ErrorDetail 参数 参数类型 描述 error_code String 错误请求返回的错误码。 error_msg String 错误请求返回的错误信息。
  • 请求参数 表2 请求Header参数 参数 是否必选 参数类型 描述 X-Auth-Token 是 String 用户Token。 通过调用 IAM 服务查询用户Token接口获取(响应消息头中X-Subject-Token的值)。 表3 请求Body参数 参数 是否必选 参数类型 描述 id 是 String 实例ID。可在查询实例列表接口的ID字段获取。 delete_publicip 否 Boolean 是否删除弹性IP delete_volume 否 Boolean 是否删除磁盘
  • 响应示例 状态码: 200 成功 { "databases" : [ { "database" : { "id" : "zLKv83gBCwCqSg3BJt0m", "name" : "db01", "type" : "MYSQL", "version" : "5.0", "charset" : "UTF8", "ip" : "192.168.0.204", "port" : "3306", "os" : "LINUX64", "status" : "OFF", "instance_name" : "", "audit_status" : null, "agent_url" : [ "zrKw83gBCwCqSg3Bkt1P" ], "db_classification" : "E CS " } } ] } 状态码: 400 请求参数错误 { "error" : { "error_code" : "DBSS.XXXX", "error_msg" : "XXX" } } 状态码: 500 服务器内部错误 { "error" : { "error_code" : "DBSS.XXXX", "error_msg" : "XXX" } }
  • 响应参数 状态码: 200 表4 响应Body参数 参数 参数类型 描述 databases Array of DataBaseBean objects 数据库信息列表 total Integer 总数 表5 DataBaseBean 参数 参数类型 描述 database DataBase object 数据库信息 表6 DataBase 参数 参数类型 描述 id String 数据库ID name String 数据库名称 type String 添加的数据库类型: 枚举值:  MYSQL  ORACLE  POSTGRESQL  SQLSERVER  DAMENG  TAURUS  DWS  KINGBASE  GAUSSDBOPENGAUSS  GREENPLUM  HIGHGO  SHENTONG  GBASE8A  GBASE8S  GBASEXDM  MONGODB  DDS version String 数据库版本 charset String 数据库字符集 ip String 数据库IP port String 数据库端口 os String 数据库操作系统 status String 开启状态(1:开启,0:关闭) instance_name String 数据库实例名 audit_status String 数据库的运行状态 枚举值:  ACTIVE  SHUTOFF  ERROR agent_url Array of strings agent的唯一ID db_classification String 数据库分类,取值范围: RDS(表示RDS数据库)和 ECS(自建数据库) 状态码: 400 表7 响应Body参数 参数 参数类型 描述 error Object 错误信息返回体。 表8 ErrorDetail 参数 参数类型 描述 error_code String 错误请求返回的错误码。 error_msg String 错误请求返回的错误信息。 状态码: 403 表9 响应Body参数 参数 参数类型 描述 error Object 错误信息返回体。 表10 ErrorDetail 参数 参数类型 描述 error_code String 错误请求返回的错误码。 error_msg String 错误请求返回的错误信息。 状态码: 500 表11 响应Body参数 参数 参数类型 描述 error Object 错误信息返回体。 表12 ErrorDetail 参数 参数类型 描述 error_code String 错误请求返回的错误码。 error_msg String 错误请求返回的错误信息。
  • URI GET /v1/{project_id}/{instance_id}/dbss/audit/databases 表1 路径参数 参数 是否必选 参数类型 描述 project_id 是 String 项目ID instance_id 是 String 实例ID 表2 Query参数 参数 是否必选 参数类型 描述 status 否 String 实例状态 ON :开启 OFF : 关闭 offset 否 String 偏移量 limit 否 String 查询记录数
  • Python 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 # coding: utf-8 from huaweicloudsdkcore.auth.credentials import BasicCredentials from huaweicloudsdkdbss.v1.region.dbss_region import DbssRegion from huaweicloudsdkcore.exceptions import exceptions from huaweicloudsdkdbss.v1 import * if __name__ == "__main__": # The AK and SK used for authentication are hard-coded or stored in plaintext, which has great security risks. It is recommended that the AK and SK be stored in ciphertext in configuration files or environment variables and decrypted during use to ensure security. # In this example, AK and SK are stored in environment variables for authentication. Before running this example, set environment variables CLOUD_SDK_AK and CLOUD_SDK_SK in the local environment ak = os.getenv("CLOUD_SDK_AK") sk = os.getenv("CLOUD_SDK_SK") credentials = BasicCredentials(ak, sk) \ client = DbssClient.new_builder() \ .with_credentials(credentials) \ .with_region(DbssRegion.value_of("cn-north-4")) \ .build() try: request = UpdateAuditSecurityGroupRequest() listSecuritygroupIdsbody = [ "f0fbec06-bcf6-4c7e-99fa-f0ddfbb1d9bd" ] request.body = SecurityGroupRequest( securitygroup_ids=listSecuritygroupIdsbody, resource_id="062212d8-8e30-4783-9671-43f3f1f3bb1e" ) response = client.update_audit_security_group(request) print(response) except exceptions.ClientRequestException as e: print(e.status_code) print(e.request_id) print(e.error_code) print(e.error_msg)
  • Go 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 package main import ( "fmt" "github.com/huaweicloud/huaweicloud-sdk-go-v3/core/auth/basic" dbss "github.com/huaweicloud/huaweicloud-sdk-go-v3/services/dbss/v1" "github.com/huaweicloud/huaweicloud-sdk-go-v3/services/dbss/v1/model" region "github.com/huaweicloud/huaweicloud-sdk-go-v3/services/dbss/v1/region" ) func main() { // The AK and SK used for authentication are hard-coded or stored in plaintext, which has great security risks. It is recommended that the AK and SK be stored in ciphertext in configuration files or environment variables and decrypted during use to ensure security. // In this example, AK and SK are stored in environment variables for authentication. Before running this example, set environment variables CLOUD_SDK_AK and CLOUD_SDK_SK in the local environment ak := os.Getenv("CLOUD_SDK_AK") sk := os.Getenv("CLOUD_SDK_SK") auth := basic.NewCredentialsBuilder(). WithAk(ak). WithSk(sk). Build() client := dbss.NewDbssClient( dbss.DbssClientBuilder(). WithRegion(region.ValueOf("cn-north-4")). WithCredential(auth). Build()) request := &model.UpdateAuditSecurityGroupRequest{} var listSecuritygroupIdsbody = []string{ "f0fbec06-bcf6-4c7e-99fa-f0ddfbb1d9bd", } request.Body = &model.SecurityGroupRequest{ SecuritygroupIds: listSecuritygroupIdsbody, ResourceId: "062212d8-8e30-4783-9671-43f3f1f3bb1e", } response, err := client.UpdateAuditSecurityGroup(request) if err == nil { fmt.Printf("%+v\n", response) } else { fmt.Println(err) } }
  • 响应参数 状态码: 200 表4 响应Body参数 参数 参数类型 描述 result String 响应状态 状态码: 400 表5 响应Body参数 参数 参数类型 描述 error Object 错误信息返回体。 表6 ErrorDetail 参数 参数类型 描述 error_code String 错误请求返回的错误码。 error_msg String 错误请求返回的错误信息。 状态码: 403 表7 响应Body参数 参数 参数类型 描述 error Object 错误信息返回体。 表8 ErrorDetail 参数 参数类型 描述 error_code String 错误请求返回的错误码。 error_msg String 错误请求返回的错误信息。 状态码: 500 表9 响应Body参数 参数 参数类型 描述 error Object 错误信息返回体。 表10 ErrorDetail 参数 参数类型 描述 error_code String 错误请求返回的错误码。 error_msg String 错误请求返回的错误信息。
  • 审计日志隐私的合规配置 由于审计日志中的SQL请求语句和结果集中可能包含用户的隐私数据,建议对审计日志开启隐私数据保护,以防止违反隐私保护相关合规要求。 通过配置如下可满足隐私数据的合规要求: 开启“隐私数据脱敏”开关:开启后会对审计日志中的隐私数据进行脱敏存储。 关闭“存储结果集”开关:关闭后,审计日志含有隐私信息的结果集将不会存储到审计日志中。 开启所有的隐私保护规则。 图4 审计日志隐私合规配置
  • 审计报表的合规配置 为了能够更及时、准确地了解合规状况,建议开启审计报表计划任务。 建议您优先设置如图2所示的报表计划任务。 图2 报表合规设置项 单击“设置任务”可对计划任务的参数进行设置,参数说明如表1所示。 图3 选择计划任务参数 表1 计划任务参数说明 参数名称 参数说明 取值样例 启动任务 启动当前任务的开关。 关闭: 开启: 消息通知 生成报表后是否发送通知。 关闭: 开启: 消息通知主题 “消息通知”选择开启时在此项选择预设的消息通知主题。 - 报表类型 选择报表生成的周期类型。 日报:若每天审计日志量超过1000万条,建议选择日报。 周报:若每天的审计日志量超过1万但不超过1000万条,建议选择周报。 月报:若每天审计日志量不超过1万条,可以选择月报。 周报 执行方式 计划任务创建后执行的次数。 周期执行:按照报表类型循环周期性执行。 执行一次:计划任务执行一次之后不再执行。 周期执行 执行时间 目标任务执行的具体时间点,可选择24小时内的任一整点时间。 创建任务后自动执行,建议选择在工作负载较低的时间段,如:凌晨。 2点 数据库 选择需要执行目标任务的数据库,可选择全部数据库,也可选择具体的单个数据库。 全部数据库
  • FullAccess敏感权限配置 DBSS的full权限集涉及部分用户的敏感权限,比如订单支付、obs桶创建和文件上传、委托的创建及委托权限设置等。 这部分权限对用户资产影响较大,故不在系统预制权限集中添加,需通过说明文档方式,由用户手动添加。 相关敏感权限说明如表1所示,权限详情如下: "obs:bucket:CreateBucket", "obs:object:PutObject", "bss:order:pay", "iam:agencies:createAgency", "iam:permissions:grantRoleToAgency", "iam:permissions:grantRoleToAgencyOnEnterpriseProject", "iam:permissions:grantRoleToAgencyOnDomain", "iam:permissions:grantRoleToAgencyOnProject" 表1 敏感权限说明 敏感权限项 使用场景说明 是否为global权限 敏感权限规避措施 obs:bucket:CreateBucket agent在CCE场景部署时,如果上传的obs桶不存在,则会调用该接口创建obs桶。上传的obs桶名固定为:dbss-audit-agent-{project_id},project_id为当前实例所在的项目id。 备份和风险导出功能场景,如果选择的桶不存在,则会创建obs桶。 是 如不涉及权限使用场景,可以不配置该权限。 如涉及,可以提前使用有权限的账号创建要使用的obs桶即可。 obs:object:PutObject agent在CCE场景部署时,将实例配置信息上传到obs桶。 是 如不涉及权限使用场景,可以不配置该权限。 如需使用,必须配置该权限才能将实例信息正常导出,无规避措施。 iam:agencies:createAgency iam:permissions:grantRoleToAgency iam:permissions:grantRoleToAgencyOnEnterpriseProject iam:permissions:grantRoleToAgencyOnDomain iam:permissions:grantRoleToAgencyOnProject 备份和风险导出场景,创建名为"dbss_depend_obs_trust"的委托并对其授予obs操作相关权限。 dws免agent场景,dws会创建名为"DWSAccessLTS"的委托,并对其授予访问lts的权限,用于将审计日志上传到租户的lts中。dbss会创建名为"dbss_dws_lts_trust"的委托,并对其授予lts访问权限,用于后续从lts下载审计日志。 是 如不涉及权限使用场景,可以不配置该权限。 使用有权限的账号开启该功能。 bss:order:pay 购买审计实例时,进行订单支付。 否 如不涉及权限使用场景,可以不配置该权限。 使用有权限的账号提前购买实例。 父主题: 权限管理
  • 计费示例 假设您在2023/06/08 9:59:30创建了一个自定义密钥,然后在2023/06/08 10:45:46将其删除。计费周期内使用密钥进行API调用36594次,计费周期如下: 第一个计费周期为9:00:00 ~ 10:00:00,在9:59:30 ~ 10:00:00间产生费用,该计费周期内的计费时长为30秒。 第二个计费周期为10:00:00 ~ 11:00:00,在10:00:00 ~ 10:45:46间产生费用,该计费周期内的计费时长为2746秒。 您需要为每个计费周期付费,各项资源单独计费,计费公式如表 计费公式所示。产品价格详情中标出了资源的每小时价格,您需要将每小时价格除以3600,得到每秒价格。 表2 计费公式 资源类型 计费公式 自定义密钥 密钥实例费用 * 时长+密钥请求API次数 * API请求费用
  • 计费周期 按需计费KMS资源按小时计费,密钥实例费用每天结算一次(以UTC+8时间为准),密钥API请求费用每月结算一次(以UTC+8时间为准),结算完毕后进入新的计费周期。计费的起点以密钥创建成功的时间点为准,终点以密钥计划删除的时间点为准。 例如,您在8:45:30创建了一个自定义密钥,然后在9:40:08将其删除,则计费周期为8:00:00 ~ 10:00:00,在8:45:30 ~ 8:55:30间产生费用,该计费周期内的计费时长为600秒。
  • 适用计费项 以下计费项支持按需计费。 表1 适用计费项 计费项 说明 密钥管理服务 按需创建的密钥实例费用以及密钥产生的API请求费用。 凭据管理服务 按需创建的凭据实例费用以及绑定密钥后产生的密钥API请求费用。 假设您创建了一个密钥算法为AES_256的对称密钥,在创建页面的底部,您将看到所需费用的明细,如图 费用示例所示。 图1 费用示例 费用计算将包括以下部分: 密钥实例费用:创建后的密钥按照时长计费。 API请求费用:创建密钥后按照API请求次数计费,每个密钥每月有20000次的免费请求次数。
  • 如何解决代码提交冲突? 当代码提交冲突产生时,您可以将远程代码仓库拉取(pull)到本地仓库的工作区,这时Git会将可以合并的修改内容进行合并,并将不能合并的文件内容进行提示,开发者只需要对提示的冲突内容进行修改即可再次推送到远程仓库(add → commit → push),这时冲突就解决完毕了。 如下图所示,在做拉取(pull)操作时,Git提示您,一个文件合并时产生了冲突。 在修改冲突文件时应该考虑清楚,必要时要与冲突方联系协商解决,避免覆盖他人代码。 git pull可以理解为 git fetch 的操作 + git merge的操作,其详细说明如下: git fetch origin master #从远程主机的master分支拉取最新内容 git merge FETCH_HEAD #将拉取下来的最新内容合并到当前所在的分支中 在merge的时候,会将有冲突不能合并的内容做出提示。
  • 如何避免冲突的产生? 代码提交、合并冲突经常发生,但只要在代码开发前,做好仓库预处理工作,就能有效的避免冲突的产生。 在示例:冲突的产生与解决中,开发者02(02_dev)成功的解决了提交远程仓库时遇到的冲突问题,此时他的本地仓库与远程仓库的最新版本内容是一样的,但是开发者01(01_dev)本地仓库和远程仓库仍然是有版本差异的,此时如果直接推送本地仓库(push),仍然会产生冲突,那么如何避免呢? 方式一(推荐新手使用): 如果开发者本地的仓库不常更新使用,在做本地修改时,可以重新clone一份远程仓库的内容到本地,修改后再次提交,这样简单直接的解决了版本差异问题,但缺点是如果仓库较大、更新记录较多,clone过程将耗费一定的时间。 方式二: 如果开发者每天都要对本地仓库进行修改,则建议在本地新建一条开发分支进行代码修改,在要提交远程仓库时,切换到master分支并将远程仓库的最新master分支内容拉取到本地,在本地进行分支合并,对产生的冲突进行修复,成功将内容合并到master分支后,再提交到远程仓库。
  • 对合并请求进行检视、审核与合入 当检视人、审核人、合并人收到系统的分支合并请求通知邮件时,请按以下步骤进行操作。 进入目标仓库详情页。 切换到“合并请求”页签,单击目标合并请求名称,查看详情。 对目标合并请求进行检视。 检视人与审核人均可对合并请求进行检视并给予检视意见,如果无修改意见,检视人可单击“检视通过”完成检视。 对目标合并请求进行审核。 审核人可通过单击“拒绝”或“通过”对合并请求进行审核。 通过合并请求门禁。 表2 合入条件说明 合入条件 说明 代码合并冲突 当源分支代码与目标分支代码产生合并冲突时,需要先解决冲突才可进行下一步操作,解决代码冲突可参考解决合并请求的代码冲突。 评审意见门禁 当发起人解决所有检视人或审核人的评审意见后,门禁显示通过,更多门禁详情请参考评审意见门禁详解。 流水线门禁 当最新commit或者预合并commit拉起并成功执行流水线时,门禁显示通过,更多门禁详情请参考流水线门禁详解。 E2E单号未关联 当合并请求关联工作项后,门禁显示通过,更多门禁详情请参考E2E单号关联门禁详解。 星级评价未通过 当指定人员进行星级评价后,门禁显示通过,更多门禁详情请参考星级评价门禁详解。 检视门禁 当已检视的检视人数达到最小检视人数时,门禁显示通过,更多门禁详情请参考检视门禁详解。 审核门禁 当已审核的审核人数达到最小审核人数时,门禁显示通过,更多门禁详情请参考审核门禁详解。 对目标合并请求进行合入。 当发起人通过以上合入条件后,合并人可单击“合入”按钮进行合入,反之,合并人可单击“关闭”将请求关闭。
  • 新建合并请求 假设管理员已经设置好了分支合并规则,当您在开发分支上完成了功能开发,并需要发起合并请求时,请按照以下流程操作。 进入目标仓库详情页。 切换到“合并请求”页签。 单击“新建”按钮,选择要合并的分支。 如上图在本示例中将刚完成开发任务的Dev分支合并到master分支中。 支持源分支选择Fork仓库的分支。 单击“下一步”按钮,此时系统会检测两条分支是否有差异。 如果分支没有差异,系统会做出提示,且不能新建合并请求。 如果分支存在差异,则进入“新建合并请求”页面。 在“新建合并请求”页面的下方可以看到两条分支的文件差异对比详情、要合并分支的提交记录。 根据下表参数说明,填写页面信息。 表1 参数说明 参数 说明 更改分支 单击可返回上一步更改需要合并的分支。 模板 如果仓库管理员或所有者已为该仓库创建合并请求模板,您可以直接选择使用模板。 标题 输入合并请求的标题。 描述 会结合分支合并情况与要合并分支的提交(commit)备注生成默认值,您可以根据项目情况进行修改。 说明: 该输入框采用markdown格式,字符数限制在5000字符以内,即将超出上限时,使用顶部的操作按钮会按照markdown的语法替换内容。 关联工作项 可选择将合并动作关联到某个工作项,以起到自动改变工作项状态的作用。 合并人 在合并请求满足合入要求时,一般是所有审核人审核通过、所有问题都被解决(可设置不解决也能合并),合并人有权限执行合并操作(单击按钮)、也有权限关闭合并请求。 检视人 被指定参与合并分支检视,可以提出问题给发起人。 审核人 被指定参与合并分支评审,可以给出审核意见(审核通过、拒绝),也可以提出问题给发起人。 合并后删除源分支 可选择是否合并后删除源分支,初始会带入合并请求设置中预设状态。 Squash合并 开启Squash合并,可使基本分支的历史记录保持干净,并带有有意义的提交消息,而且在必要时可以更简单地恢复,详情请参考Squash合并。 单击“新建合并请求”按钮,可以完成合并请求的提交,页面会跳转到该“合并请求详情页”。 在合并请求详情中,可以看到合入条件达成的状态、合并人、检视人、审核人、所关联的工作项等信息,同时可以查看可留下评审意见,可标注评审意见为待解决状态,并可看到该合并涉及的所有动态。 “提交记录”:可以看到源分支的相关提交记录。 “文件变更”:可以看到此次合并的变更内容,并可具体筛选出新增、修改、删除、重命名等变更种类。 “流水线”:可以看到门禁流水线的信息。 当发起分支合并请求时,其相关人员(审核人、合并人)会收到提醒邮件。审核人不能为合并请求创建者。 单个文件差异超过5000行、差异文件个数超过100个时,建议使用客户端合并后,推送到代码托管。 新建合并请求后自动跳转到合并请求页,只有流水线正在排队或者运行中,而合并请求其他合入条件都通过时,有合入权限成员可勾选“合并请求流水线成功后自动合入”。
  • 合并请求列表 在仓库详情的“合并请求”页签中,可以看到“合并请求列表”页面。 可以切换、查看不同状态的合并请求。 通过单击请求标题可以进入合并请求详情页。 可以查看请求的简要信息,包括:涉及的分支、创建时间、创建人。 提供了多条件维度的查找功能。 在左上方有新建合并请求入口。 开启中:代表该请求已进入检视或合并阶段,分支未合并。 已合并:代表该请求已经完成审核,并完成分支合并的动作。 已关闭:代表该请求被取消,分支未产生实际合并。 所有:显示所有状态的合并请求。
  • 基于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白名单的机器才可以从界面下载源码压缩包。 如果您误删了分支,可提交工单联系技术支持处理。 另外在控制台中您还可以对分支进行相关的设置: 合并请求设置 默认分支管理 分支保护设置
  • 仓库名称页签:查看分支或标签版本的文件详情内容 “仓库名称”页签位于仓库详情中,其默认状态显示主分支的文件详情内容,如下图所示。 其中包含字段: 文件:文件或文件夹的名称。 提交信息:此文件或文件夹的上次提交信息(commit的-m),单击可定位到此次提交记录。 创建者:此文件或文件夹的上次提交创建者。 更新时间:此文件或文件夹的上次更新时间。 编辑、删除操作需要填写提交信息,相当于git commit中的-m消息,其可以用于11.7-查看关联工作项。
  • 历史页签:查看分支或标签版本的提交历史 “历史”页签位于仓库详情中,其显示分支或标签版本的提交历史,如下图所示。 在这个页面,可以对提交历史做如下操作: 单击“提交记录名称”,可以跳转到该次提交的详情中。 单击可扩展功能如下: 新建分支。 新建Tag:可针对此次提交补打标签。(什么是标签?) Cherry-Pick:把此次提交作为最新的提交覆盖到某条分支上,这是一种版本找回方式。 Revert:还原此次提交。 查看代码。
  • 管理仓库文件 单击文件名称,可对该文件进行管理,功能如下: 当您将浏览器窗口最大化时,上图下拉菜单中的功能会平铺展示。 文件名称:查看文件详细内容。 表1 界面说明 界面功能 功能说明 文件容量 显示此时该文件的容量大小。 全屏显示 将该文件窗口扩展为全屏。 复制源代码 复制所展开文件内容到剪切板。 查看原始数据 可查看该文件的原始数据。 编辑 在线编辑文件。 下载 直接将此文件下载到本地。 删除 单独删除文件。 文件内容 显示文件的全部内容。 图标 单击可添加检视意见。 修改追溯:查看文件的修改历史并追溯。 在这个页面,修改者与修改内容相互对应,单击“提交信息名称”可以跳转到该次提交的详情中。 历史:查看文件的提交历史。 在这个页面,可以对提交历史做如下操作: 单击“提交记录名称”,可以跳转到该次提交的详情中。 单击可扩展功能如下: 新建分支。 新建Tag:可针对此次提交补打标签。(什么是标签?) Cherry-Pick:把此次提交作为最新的提交覆盖到某条分支上,这是一种版本找回方式。 Revert:还原此次提交。 查看代码。 对比:提交的差异对比。 在代码托管控制台对比出的差异,其展现形式优于Git Bash客户端,可以在界面选择不同提交批次,进行差异对比。 本服务中的差异对比,其对比结果其实是显示您从左侧仓库版本向右侧仓库版本合并时对右侧仓库内文件所产生的影响,所以如果您想全面了解两个文件版本的差异,可以调整左右位置后再次对比,结合两次结果了解全部差异。
  • 文件列表 文件列表位于该仓库“文件”页签的左侧,文件列表包含以下功能: 单击分支名称,切换分支、标签:切换后的分支、标签后会显示对应版本的文件目录。 单击检索图标:单击弹出搜索页面,可对文件列表进行搜索定位。 单击图标,可扩展功能如下: 新建文件/重命名文件/新建目录/新建子模块支持创建多级目录,多级目录以/分隔,如'java/com'。 新建文件。 在代码托管仓库控制台新建文件,等同于“文件的新建 → add → commit→ push”操作,会生成提交记录。 在“新建文件”页面,填写文件名称,选择目标模板类型,选择编码类型,填写文件内容及提交信息后,单击“确定”完成新文件的创建。 “提交信息”字段相当于git commit中的-m消息,可以用于11.7-查看关联工作项。 新建目录。 在代码托管仓库控制台新建目录,其实是一次“文件夹结构的新建 → add → commit→ push”,会生成提交记录。 新建目录后在目录的最深层会默认新建一个.gitkeep文件,这是因为Git不允许提交空文件夹。 在“新建目录”页面,填写目录名称,及提交信息后,单击“确定”完成新目录的创建。 新建子模块。 上传文件。 在代码托管仓库控制台上传文件,其实是一次“文件的新建 → add → commit→ push”,会生成提交记录。 在“上传文件”页面,选择上传的目标文件,填写提交信息后,单击“确定”完成新文件的上传。 鼠标停留在文件夹名称处,单击显示的图标,可该文件夹下进行以上操作。 鼠标停留在文件名称处,单击显示图标即可修改文件名称。 在代码托管仓库控制台修改文件名称,其实是一次“文件的名称修改 → add → commit→ push”,会生成提交记录。 单击文件名称可将该文件内容显示于页面右侧,可对文件进行修改文件内容、追溯文件修改记录、查看历史记录、对比等操作。
  • 工作方式 将“项目公共仓”fork出一个“个人公共仓”。 将“个人公共仓”clone到“本地仓库”。 操作“本地仓库”,修改完成后提交到“个人公共仓”。 为“个人公共仓”提交一个pull request给项目维护者,申请代码合入“项目公共仓”。 项目维护者在本地review、验证本地提交,审核通过后push进入“项目公共仓”。 如果开发人员A的代码未被审核通过合入“公共仓库”,而此代码对开发人员B有借鉴作用,开发人员B可以直接从开发人员A的“个人公共仓”拉取代码。
  • 工作方式 master分支: 生产分支,最稳定的版本,一直是ready to deploy状态。不接受开发人员直接commit,只接受从其他分支merge操作。在很多企业中,这个分支被默认开启分支保护,只有维护者可以操作。 hotfix分支: 从master分支拉取的临时修复分支,用于解决一线紧急bug。bug解决后需要合入master分支并打上新的版本号,这个修改也需要同时合入develop分支。 develop分支: 从master分支拉取的开发分支,用于功能集成。包含所有要发布到下一个Release的代码用于开发集成、系统测试。 release分支: 临近既定的发布日,就从develop分支上拉取一个release分支,任何不在当前分支中的新功能都推到下个发布中。release分支用于发布,所以从当前时间点之后新的功能不能再加到这个分支上,这个分支只做Bug修复、文档生成和其它面向发布的任务。当对外发布的工作都完成了,release分支合并到master分支并分配一个版本号打好Tag;另外,这些从release分支新做的修改要反向合并回develop分支。 feature分支: 开发者使用的特性分支,父分支是develop分支,当新功能完成时,合入develop分支。新功能提交从不直接与master分支交互。
  • 优点 使用一个用于发布准备的专门分支(release分支),使得一个团队可以在完善当前的发布版本的同时,可以在develop分支并行继续开发下个版本的功能。这也打造了可视化的发布阶段,团队成员都可以在仓库网状结构中可以看到发布状态。 使用紧急修复分支(hotfix分支)让团队可以处理紧急问题的同时而不打断其它工作或是等待下一个发布再合入hotfix修改。您可以把hotfix分支想成是一个直接在master分支上处理的临时发布。 大型项目人员协作频繁,流程较多,合理的多角色分支帮助研发有条不紊进行。 更符合devops理念。
  • Tips:如何尽量避免产生冲突和不合理的提交历史? 开发人员在开发一个新功能之前,一定要在本地同步中央仓库最新代码,使自己的工作基于最新的代码之上;开发完成后,在提交新功能到中央仓库前,需要先fetch中央库的新增提交,并rebase自己的提交。这样做的目的是,把自己的修改加到中央仓别人已经提交的修改之上,使最终的提交记录是一个完整的线性历史,而不是环形,工作流举例如下图所示。 开发人员A和开发人员B同时在某个时间拉取了中央仓库的代码。 开发人员A先完成了自己的工作,并提交到中央仓库。 开发人员B需要在本地执行git pull –rebase中央仓库的新提交,这时开发人员B的本地仓库就包含了开发人员A修改的内容,并在A的基础上增加了自己的修改。 开发人员B将代码推送到中央仓库。
  • Git工作流概述 什么是Git工作流?你可以理解为代码管理的分支策略,它不仅仅是版本管理范畴,更服务于项目流程管理和团队协同开发。所以,有必要制定适合自己研发场景的工作流。 下面介绍四种工作流的工作方式、优缺点,以及使用中的一些注意事项。 集中式工作流 功能分支工作流 Git flow工作流(推荐) Forking工作流 研发团队可以根据实际研发场景制定合理的工作流,能有效提高项目管理水平和团队协同开发能力, 并通过CodeArts Repo平台,高效、安全的管理代码资产,将更多的精力集中在业务开发上,实现持续集成、持续交付和快速迭代的目标。 父主题: Git工作流
共100000条