华为云用户手册

查看代码组详情 在代码组列表中单击代码组名称可进入该代码组的详情页面， 代码托管服务 提供了丰富的控制台操作，详情如下。 表1 页签说明 功能说明 页签说明 代码仓（组） 用于展示代码组的数量、仓库数量、开启中的MR的数量和成员数量等信息。同时您也可以新建仓库和查看未锁定的仓库。 成员 代码组成员管理页面，支持添加成员，调整代码组成员角色。 设置 此代码组的设置入口，代码组所有成员均可查看，但是仅支持项目管理员或代码组所有者修改。 另外代码组详情页框架上还提供以下功能的快捷入口： 获取仓库地址：可通过单击“SSH”或“HTTPS”后的图标，获取仓库地址。 ：单击该图标，可关注该代码组。 ：在代码组下单击该图标，可查看仓库数目，并进入每个仓库，查看代码组成员并进行代码组成员设置，创建新的子代码组或仓库，按照模板创建新的仓库，以及导入外部仓库。在仓库下单击该图标，可进行关联工作项、成员管理和删除仓库操作。 父主题： 使用代码组

查看代码组列表 您可以通过以下方式进入代码托管服务代码组列表页。 进入软件开发生产线首页，单击“服务”图标下的“代码托管”，默认展示我参与的仓库列表页，单击“代码组”下的任一菜单，即可进入代码托管服务代码组列表页。 在这里您可以完成新建代码组、配置代码组等操作。 ：单击该图标，可进入新建代码组页面。 ：单击该图标，关注代码组。可在我关注的代码组中查看该代码组。 ：单击代码组所在行右侧的该图标，可进入子代码组首页。 ：单击父代码组后的该图标，可展示“仓库”、“成员”、“设置”和“新建子代码组”图标。 ：单击该图标，可直接进入代码仓（组）列表页面。 ：单击该图标，可直接进入代码组成员列表页面。 ：单击该图标，可直接进入代码组“设置”页签下 的代码组信息页面。 ：单击该图标，可直接进入新建子代码组页面。 个人首页：支持查看“我关注的”、“我参与的”及“我创建的”等分类的代码组。右上角支持查看“最近创建”和“最近更新”的代码组。 父主题： 使用代码组

新建代码组 进入项目或父组织中，单击图标下拉框选择“新建代码组”，进入新建代码组页面，根据下表填写基本信息，单击“确定”，完成代码组的新建，代码组最多支持三层目录。 表1 新建代码组参数说明 字段说明 是否必填 备注说明 归属项目 是 代码组必须存在项目下。 如果账号下没有项目请在项目选择框中选择“新建项目”会先弹出“新建项目”页面，这时建立的项目是Scrum。 说明： 只有通过“代码托管”首页入口新建代码组时，才能新建项目。 代码组路径 否 代码组路径对应建仓接口的参数groupId。如果groupId为空，则表示创建项目下的仓库，没有对应的代码组。您可根据自己实际需求选择代码组路径。代码组路径范围是所有首层代码组、子代码组的根组织路径。 代码组名称 是 请以大小写字母、数字、下划线开头，可包含大小写字母、数字、中划线、下划线、英文句点，但不能以.git、.atom或.结尾。代码组和仓库总长度限制为256字符。 描述 否 为您的代码组填写描述，限制2000字符。 是否公开 是 可选择私有和公开只读，默认选择私有。 私有 仅对代码组成员可见。私有代码组下的子代码组和仓库的公开性只能为“私有”。 公开只读 代码组对所有访客公开可读，但不出现在访客的代码组列表及搜索中。公开代码组下的子代码组和仓库的公开性支持私有和公开只读两种。

查看仓库的统计信息 在仓库详情中的“仓库统计”页签，可以查看仓库的相关统计信息，详情如下： 仓库信息概要：主要显示Git库容量、LFS容量、分支数量、Tags数量、成员数量、提交数量。可选择分支，对仓库趋势图、贡献者统计、提交统计的统计范围产生影响。（不会影响仓库信息概要） 语言统计：显示仓库当前分支的各语言分布情况。 仓库趋势图：显示仓库当前分支的提交分布情况。 贡献者统计：统计当前分支中代码提交者们的贡献度（提交次数、代码行数）。 提交统计：按不同维度（每周、每天、每小时）统计代码提交活跃度。 仓库成员可以触发代码贡献度统计与语言比例统计。 因资源限制，每个仓库一天可以统计10次。 每个用户一天可以统计1000次。 统计完成，将显示每一位用户在截止时间之前的全部新增、删除的代码行数量（“+”表示新增，“-”表示删除）。 merge（将两个或两个以上的开发历史合并在一起的操作）节点的提交均不被统计。

查看仓库的动态 在仓库详情中的“动态”页签，可以查看截止当前仓库的全部动态。 全部：展示截止当前该仓库的所有操作记录。 推送：展示截至当前该仓库所有的推送操作记录，例如推送代码、新建/删除分支等。 合并请求：展示截至当前该仓库所有合并请求的操作记录，单击合并请求的序号可查看详情，例如新建/关闭/重开/合入合并请求等。 检视意见：展示截至当前该仓库所有检视意见记录，单击提交号可查看详情，例如添加/删除检视意见等。 成员：展示截至当前该仓库所有成员的管理记录，例如添加/移除成员、编辑成员权限等。 展示内容为操作者、具体的操作内容及操作时间。 支持选择时间范围、操作人等条件进行筛选查询。

服务扩展点授权 表1 服务扩展点授权参数 参数 说明 连接名称 必填，根据自定义填写名称，连接名称最大长度不超过256个字符。 验证方式 必填，根据需要选择： 如果选择“OAuth认证”，单击“授权并确定”，将自动跳转到GitHub登录页面，输入GitHub登录的账号和密码后，单击“Authorize huaweidevcloud”即可完成授权。授权成功后，新建扩展点页面将出现“授权成功”，页面右上角会弹出“新建接入点成功!”，这时您可以下拉框选择刚才创建成功的扩展点。 如果选择“AccessToken认证”，需要使用有仓库管理员权限的账号在GitHub创建的Access Token，可参考获取Access Token。

填写仓库基本信息 表1 填写仓库基本信息 参数 说明 代码组路径 非必填。默认为“/”，表示不归属于任何代码组路径。您也可以下拉框选择已有的代码组路径。 代码仓库名称 必填。请您为导入的仓库命名。需要以大小写字母、数字、下划线开头，可包含大小写字母、数字、中划线、下划线、英文句点，但不能以.git、.atom或.结尾。 描述 非必填。为仓库添加描述信息，最多不能超过2000个字符。 初始化设置 非必选。如果您已开通代码检查(CodeArts Check)服务，推荐您勾选该选项，代码仓库创建完成后，在代码检查(CodeArts Check)任务列表中，可看到对应仓库的检查任务。 可见范围 该参数为非必填。该参数表示源仓库的可见范围，包括两个选项： 公开。包含三个选项：“项目内成员只读”、“租户内成员只读”和“所有访客只读”。 私有（仓库仅对仓库成员可见，仓库成员可访问仓库或者提交代码）。 父主题： 迁移代码与同步仓库

配置项目级的合并请求规则 合并请求规则包含三个部分：合入机制、合入条件、MR设置和合并模式。 表4 合入机制的参数说明 参数 说明 合入机制 必填参数。包含两个选项： 打分机制：包含代码检视，以打分为基础，可设置最低合入分值，分值范围为0~5分。只有分数和必选评审达到门禁条件时，代码才可以合入，勾选打分机制时需设置最低分值。 审核机制：包含代码检视和合并审核两个步骤，以通过人数为基础，只有审核通过的人数达到门禁条件时，代码才可以合入。 说明： 合并请求默认为“审核机制”，可手动切换为“打分机制”。 修改合入机制后，会改变合并请求的工作流，但之前创建的合并请求仍保留之前的合入机制。 表5 合入条件参数说明 参数 说明 合入条件 非必填参数。包括两个选项： 勾选“评审问题全部解决才能合入”，如果评审意见被勾选为“这是一个需要被解决的问题”，则合入条件会提示“存在未解决的评审意见”且“合入”按钮置灰；如果只是一个普通的评审意见，则不存在“已解决”开关，也不会被合入条件拦截。 如果勾选“必须与CodeArts Req关联”，被关联的所有E2E单号校验必须通过；一个MR只能关联一个单号；可添加多个分支配置合并请求策略，支持手动输入通配符匹配，按回车确认，如：*-stable或production/*。 表6 MR设置参数说明 参数 说明 禁止合入自己创建的合并请求 勾选后，您在查看自己创建的MR时，“合入”按钮置灰，表示自己无法合入代码，需要找其他有合入权限的人合入。 禁止审核自己创建的合并请求 勾选后，您在查看自己创建的MR时，“审核”按钮置灰，自己无法审核，需要找其他有审核权限的人审核。 禁止检视自己创建的合并请求 勾选后，您在查看自己创建的MR时，“检视”按钮置灰，自己无法检视，需要找其他有检视权限的人检视。 允许仓库管理员强制合入 项目创建者和管理员有强制合入的权限，当合入条件不满足，也可通过“强行合并”按钮合入MR。 允许合并请求合并后继续做代码检视和评论 勾选后，已合入MR可继续做代码检视、评论。 是否将自动合并的MR状态标记为关闭状态（如果B MR中的所有commits都包含在A MR中，那么当A MR合并后，则B MR会自动合并。默认B MR会标记为merged状态，可以通过该选项控制将B MR标记为Closed状态） 未勾选时，自动合并的MR被标记为已合并。 勾选后，自动合并的MR的状态将会标记为关闭状态。 不能重新打开一个已经关闭的合并请求 勾选后，当分支合并请求已经关闭后，不能将其重新置回“开启”状态，右上方的“重开”按钮将隐藏。 此设置一般用于流程管控，使历史评审不会被篡改。 合并请求合入后，默认删除源分支 合并成功后，源分支将被删除。 已经设置成保护分支的源分支不会被删除。 此设置对历史合入请求，不会生效，不必担心启用此设置会丢失分支。 禁止Squash合并 勾选后，“Squash合并”按钮被禁止，且合并请求中无该功能使用入口。 新建合并请求，默认开启Squash合并 Squash合并是指Git在做两个分支间的合并时，会把被合并分支上的所有变更“压缩（squash）”成一个提交，追加到当前分支的后面作为“合并提交”（merge commit），可以使分支变得简洁。Squash合并和普通Merge合并唯一的区别体现在提交历史上：对于普通Merge而言，在当前分支上的合并提交通常会有两个提交信息；而Squash Merge只有一个提交信息。

同步仓库设置 表1 同步仓库设置的参数表格 字段名称 说明 分支设置 该参数必填。包括两个选项： 默认分支。指新建代码仓库时自动创建的主分支，例如master分支。 全部分支。指代码仓库中的所有分支，包括默认分支及其他自定义分支。 增加定时同步 非必填。 须知： 如果您勾选了此参数，导入的仓库将为镜像仓，仓库将无法提交代码，只能从源仓定时同步，并且是每24小时自动刷新一次代码，刷新内容为源仓库24小时前的内容。

集中式工作流缺点 依赖中央仓库：所有的代码都依赖于中央仓库，如果中央仓库出现问题，整个团队的开发工作都将受到影响。 代码冲突：由于所有的代码都在中央仓库中进行管理，团队成员在进行代码修改时容易发生冲突，需要通过手动解决冲突来保证代码的正确性。 需要权限管理：由于所有的代码都在中央仓库中进行管理，需要对团队成员的权限进行管理，以保证代码的安全性和可靠性。 不适合大型项目团队：对于大型项目团队而言，集中式工作流可能会导致中央仓库的管理和维护变得困难，影响开发效率和代码质量。

集中式工作流流程 创建代码仓库。Repo目前支持新建自定义代码仓库、按模板新建代码仓库、Fork已有的代码仓库，也支持从本地导入已有的代码仓库、导入Git平台的代码仓、导入SVN平台的代码仓。 开发者克隆代码仓。Repo目前支持使用SSH密钥克隆代码仓到本地、使用HHPS协议克隆代码仓到本地。 开发者在本地创建分支并开发代码或者在线创建分支分支并开发代码。 开发者提交更改的代码文件到缓存区。Repo目前支持使用Git Bash提交代码、在Eclipse提交代码。 开发者新建合并请求。 开发者解决检视意见。 Committer合入合并请求。

如何避免冲突的产生？ 代码提交、合并冲突经常发生，但只要在代码开发前，做好仓库预处理工作，就能有效的避免冲突的产生。 在示例：冲突的产生与解决中，开发者02（02_dev）成功的解决了提交远程仓库时遇到的冲突问题，此时他的本地仓库与远程仓库的最新版本内容是一样的，但是开发者01（01_dev）本地仓库和远程仓库仍然是有版本差异的，此时如果直接推送本地仓库（push），仍然会产生冲突，那么如何避免呢？ 方式一（推荐新手使用）： 如果开发者本地的仓库不常更新使用，在做本地修改时，可以重新clone一份远程仓库的内容到本地，修改后再次提交，这样简单直接的解决了版本差异问题，但缺点是如果仓库较大、更新记录较多，clone过程将耗费一定的时间。 方式二： 如果开发者每天都要对本地仓库进行修改，则建议在本地新建一条开发分支进行代码修改，在要提交远程仓库时，切换到master分支并将远程仓库的最新master分支内容拉取到本地，在本地进行分支合并，对产生的冲突进行修复，成功将内容合并到master分支后，再提交到远程仓库。

如何解决代码提交冲突？ 当代码提交冲突产生时，您可以将远程代码仓库拉取（pull）到本地仓库的工作区，这时Git会将可以合并的修改内容进行合并，并将不能合并的文件内容进行提示，开发者只需要对提示的冲突内容进行修改即可再次推送到远程仓库（add → commit → push）,这时冲突就解决完毕了。 如下图所示，在做拉取（pull）操作时，Git提示您，一个文件合并时产生了冲突。 在修改冲突文件时应该考虑清楚，必要时要与冲突方联系协商解决，避免覆盖他人代码。 git pull可以理解为 git fetch 的操作 + git merge的操作，其详细说明如下： git fetch origin master #从远程主机的master分支拉取最新内容 git merge FETCH_HEAD #将拉取下来的最新内容合并到当前所在的分支中 在merge的时候，会将有冲突不能合并的内容做出提示。

把本地第三方Git仓导到Repo 如果您是从第三方Git仓克隆到本地，并对此代码仓做修改。您可以执行如下步骤，把本地修改过的Git代码仓导入到CodeArts Repo。 进入CodeArts Repo首页，单击“新建仓库”，在“归属项目”下拉框中选择已有的项目或者“新建项目”。 仓库类型选择“普通仓库”，填写对应参数信息并取消勾选“允许生成README文件”和“选择gitignore”，完成新的代码仓库创建，并自动跳转到该代码仓库首页，单击“克隆/下载”，获取仓库地址。 执行命令git commit -m "init commit"，创建初始提交。 执行命令git remote add origin 远程仓库地址。 执行命令 git push -u origin master，把本地创建的Git仓推送到Repo新建的代码仓。

在线导入SVN平台的代码仓库到CodeArts Repo 进入CodeArts Repo首页后，单击“新建仓库”，在“归属项目”下拉框中选择已有的项目或者“新建项目”。 仓库类型选择“导入仓库”，导入方式选择“SVN”，参数填写请参考表1。 表1 导入SVN平台代码仓库的参数表格 字段名称 说明 源仓库路径 该参数必填，该参数表示要导入的仓库路径。源仓库路径需要以（http://）开头。 说明： 如果仓库过大或者网络较差时，仓库导入时间可能会超过30min。如果出现导入超时，建议使用客户端clone/push来处理，具体可参考通过Git Bash导入SVN平台的代码仓库到CodeArts Repo。 在线导入的操作方式简单，且将SVN中的分支、Tags进行平移，如果后续想在此代码仓的基础上继续开发，请利用Git Bash客户端导入，具体可参考通过Git Bash导入SVN平台的代码仓库到CodeArts Repo。 该功能需要保证被导入的仓库 域名 和服务节点网络连通。 源仓库访问权限 必填。分两种情况填写： 如果您导入的源仓可见范围是对所有访客公开，勾选“不需要校验权限”。 如果您导入的源仓可见范围是私仓，请勾选“需要校验权限”。当前支持两种鉴权方式，“通过服务扩展点”和“通过用户名密码授权”，参数填写请参考校验导仓权限。 单击“下一步”，进入“填写基本信息”页，请参考表格填写参数。 请参考表1 同步仓库设置的参数表格，填写“同步仓库”设置参数。

配置代码仓库的子模块设置 子模块（submodule）是Git为管理仓库共用而衍生出的一个工具，通过子模块您可以将公共仓库作为子目录包含到您的仓库中，并能够双向同步该公共仓库的代码，借助子模块您能将公共仓库隔离、复用，能随时拉取最新代码以及对它提交修复，能大大提高您的团队效率。 有种情况经常会遇到：某个工作中的项目A需要包含并使用项目B（第三方库，或者您独立开发的，用于多个父项目的库），如果想要把它们当做两个独立的项目，同时又想在项目A中使用项目B，可以使用Git的子模块功能。 子模块允许您将一个Git仓库作为另一个Git仓库的子目录。 它能让您将另一个仓库克隆到自己的项目中，同时还保持提交的独立。 子模块将被记录在一个名叫“.gitmodules”的文件中，其中会记录子模块的信息： [submodule "module_name"] #子模块名称 path = file_path #子模块在本仓库（父仓）中文件的存储路径。 url = repo_url #子模块（子仓库）的远程仓地址 这时，位于“file_path”目录下的源代码，将会来自“repo_url”。

校验导仓权限 Repo当前支持两种方式的校验权限，可通过服务扩展点校验权限，也可以通过用户名密码授权。 通过服务扩展点校验权限 连接名称。必填，根据自定义填写名称，连接名称最大长度不超过256个字符。 Git仓库Url。必填，输入导入源仓的URL地址。 用户名。当源代码仓库为私有时，该参数必填。该参数表示HTTPS克隆代码时的用户名，例如为GitHub的登录名称。 密码或Access Token。当源代码仓库为私有时，该参数必填。该参数表示HTTPS克隆代码时的密码或者Access Token，例如为GitHub的登录密码或者在GitHub创建的Access Token。该参数的获取方式请参考在GitHub获取Access Token。 通过用户名密码授权 您也可以勾选“通过用户名密码授权”，“用户名”填写请参考用户名参数填写，“密码或Access Token”填写请参考密码或Access Token参数填写。 父主题： 迁移代码与同步仓库

配置Git LFS Git LFS(Large File Storage)是Git的一个扩展，用于管理Git仓库中的大型二进制文件。Git LFS将大型文件存储在Git仓库之外，以避免Git仓库变得过于庞大和缓慢。Git LFS支持大多数常见的二进制文件格式，包括图像、视频、音频等。使用Git LFS，您可以将大型文件与代码分开管理，并使用Git的版本控制功能来跟踪和管理它们。Git LFS还可以锁定文件和控制版本，以确保多个用户在同时编辑大型文件时不会发生冲突。 因此，要使用Git LFS，您需要在本地安装Git LFS客户端，并在Git仓库中启用Git LFS扩展。您还需要将大型文件添加到Git LFS跟踪列表中，以便Git LFS可以正确地管理它们。 表1 安装Git LFS 操作系统 官方的安装指导链接 Windows系统 Windows Git-LFS安装指导 Linux系统 Linux Git-LFS安装指导 MacOS系统 MacOS Git-LFS安装指导 父主题： 环境和个人配置

通过E2E单号关联门禁 如果为目标仓库开启了E2E单号关联，即勾选“必须与CodeArts Req关联”。执行如下步骤，完成E2E单号关联： 进入目标仓库，切换到“合并请求”页签，单击目标合并请求名称，进入目标合并请求。 单击“详情”页中“关联工作项”旁的图标，搜索并选择目标工作项。 单击“确定”，完成E2E单号关联。 当合并请求成功关联工作项时，门禁显示为“E2E单号关联通过”。 如果您在合并代码的时候提示单个仓库容量超过2GB，不允许合并申请，请检查是否有Git提交的缓存文件所致。 MR关联工作项最大数量为100个。

IAM 用户、项目成员与仓库成员的关系 仓库成员来源于其所属项目的项目成员，项目成员主要来源于租户的IAM用户，除项目创建者所在租户外，还可以邀请其它租户下的IAM账号加入项目。如下图为IAM用户、项目成员、仓库成员的包含关系示意图。 表1 项目角色与仓库角色对应关系 项目中的角色 仓库中的角色 项目经理 项目经理（默认） 产品经理 产品经理（默认） 测试经理 测试经理（默认） 运维经理 运维经理（默认） 系统工程师 系统工程师（默认） Committer Committer（默认） 开发人员 开发人员（默认） 测试人员 测试人员（默认） 参与者 参与者（默认） 浏览者 浏览者（默认） 自定义角色 自定义角色（默认） 其中，项目产生的费用将计算在项目经理所属的租户下。 项目创建者在项目中默认为“项目管理员”，在Repo对应为“管理员（仓库所有者）”。 父主题： 管理Repo成员权限

使用URL导Git仓到Repo 进入CodeArts Repo首页后，单击“新建仓库”，在“归属项目”下拉框中选择已有的项目或者“新建项目”。 仓库类型选择“导入仓库”，导入方式选择“Git Url”，参数填写请参考表1。 表1 “获取授权”参数填写 字段名称 说明 源仓库路径 该参数必填，该参数表示要导入的仓库路径。源仓库路径需要以（http://）或（https://）开头，以（.git）结尾。 说明： 如果仓库过大或者网络较差时，仓库导入时间可能会超过30min。如果出现导入超时，建议使用客户端clone/push来处理，具体可参考导入外部仓库提示超时。 该功能需要保证被导入的仓库域名和服务节点网络连通。 源仓库访问权限 必填。分两种情况填写： 如果您导入的源仓可见范围是对所有访客公开，勾选“不需要校验权限”。 如果您导入的源仓可见范围是私仓，请勾选“需要校验权限”。当前支持两种鉴权方式，“通过服务扩展点”和“通过用户名密码授权”，参数填写请参考校验导仓权限。 单击“下一步”，进入“填写基本信息”页，请参考表格填写参数。 请参考表1 同步仓库设置的参数表格，填写“同步仓库”设置参数。 填写完参数后，会自动跳转到新建仓库的“代码”页面。 如果在代码仓库列表页，新建代码仓库名称颜色为灰色，且仓库名称旁有红色感叹号，表示该仓库导入失败，可能原因：用户名或者密码/Access Token错误。可以将该代码仓删除，按照如上步骤操作，重新导入外部仓库。 当前Git支持的外部导入源包括：bitbucket.org、code.aliyun.com、coding.net、git.qcloud.com、gitee.com、github.com、gitlab.com、visualstudio.com、xiaolvyun.baidu.com。 在新建代码仓库后，仅有创建者能够访问该仓库。其他项目成员需要手动添加到仓库中，并分配相应的权限。因此，您需要根据需求，手动为代码仓库添加成员并为新增成员配置访问权限。 父主题： 迁移第三方Git仓到Repo

在Windows中使用密钥对方式进行加密、解密 下载并安装最新的Windows Git客户端，下载最新基于Windows的git-crypt，把下载到的exe文件放到Git安装目录下的“cmd”文件夹中。 执行如下命令，在本地生成密钥对。 打开“Git Bash”，并进入本地代码仓库。 执行如下命令，在Git代码仓库中创建“.git-crypt”文件夹，文件夹包含加密文件所需的密钥和配置文件。 git-crypt init 执行如下命令，把密钥文件导出到C:/test目录并命名为KeyFile。 git-crypt export-key /c/test/keyfile 执行完上述步骤，您可以到密钥导出的文件路径进行验证，确认是否已成功生成密钥。持有这个密钥文件的计算机，可以解密对应的加密文件。 执行如下命令，为代码仓库配置加密范围。 在仓库的根目录下新建一个名为“.gitattributes”的文件。 打开“.gitattributes”文件，设置加密范围，语法如下。 文件名或文件范围 filter=git-crypt diff=git-crypt 下面给出四个示例。 FT/file01.txt filter=git-crypt diff=git-crypt #将特定文件加密，这里加密的是FT文件夹下的file01.txt *.java filter=git-crypt diff=git-crypt #将 .java类型文件加密 G* filter=git-crypt diff=git-crypt #将 文件名为 G 开头的文件加密 ForTest/** filter=git-crypt diff=git-crypt #将 ForTest 文件夹下的文件加密 如果创建.gitattributes文件时提示“必须键入文件名”，可以将文件名填写成 “.gitattributes.”即可创建成功，如果使用Linux指令创建文件，则不会出现此问题。 注意不要将.gitattributes保存成txt文件，否则配置会无效。 进行文件加密。 在仓库根目录打开Git bash，执行如下指令即可完成加密，加密后可看到目前文件的加密状态。 git-crypt status 加密执行后，在您的本地仓库仍能明文方式打开和编辑这些加密文件，这是因为您本地仓库有密钥存在。 这时您可以使用add 、commit、push组合将仓库推送到代码托管仓库，此时加密文件将一同被推送。 加密文件在代码托管仓库中将以加密二进制方式存储，无法直接查看。如果没有密钥，就算将其下载到本地，也无法解密。 “git-crypt status”只会加密本次待提交的文件，对本次未发生修改的历史文件不会产生加密作用，Git会对此设定涉及的未加密文件做出提示（见上图中的Warning），如果想将仓库中的对应类型文件全部加密，请使用“git-crypt status -f”。 在让团队合作中 -f （强制执行）具有一定的风险，请谨慎使用。 进行文件解密。 确认本机器Git安装路径下存在git-crypt文件。 将仓库从代码托管克隆到本地。 获取加密此仓库的密钥文件，并存储于本地计算机。 进入仓库目录，右键打开Git bash。 执行解密指令，执行后无回显，则为执行成功。 git-crypt unlock /C/test/KeyFile #请将 /C/test/KeyFile 更换为您实际的密钥存储路径

git-crypt加密在团队合作中的应用 很多时候，团队需要在代码仓库中存储限制公开的文件，这时可以优先考虑使用“CodeArts Repo” + “Git” + “git-crypt”的组合，来实现部分文件在仓库分布式开源中的加密。 通常，直接使用密钥对方式的加密就能满足限制部分文件访问的需要。 当团队需要将加密文件设置不同的秘密级别时，可以使用GPG方式加密，这种方式支持您对同一个仓库的不同文件使用不同的密钥加密，将不同密级的密钥分别随仓库共享给组织内的伙伴，即可实现文件的定向分级限制访问。

Linux、Mac平台的git-crypt、GPG安装 Linux平台安装git-crypt、GPG Linux安装依赖环境。 Software Debian/Ubuntu package RHEL/CentOS package Make make make A C++11 compiler (e.g. gcc 4.9+) g++ gcc-c++ OpenSSL development files libssl-dev openssl-devel Linux环境下，使用源码编译方式安装git-crypt。 下载源码 make make install 安装到指定目录。 make install PREFIX=/usr/local Linux环境下，使用源码编译方式安装GPG。 下载源码 ./configure make make install 使用Debian包安装git-crypt。 下载源码 Debian打包可以在项目Git仓库的“debian”分支中找到。 软件包是用“git-buildpackage”构建的，如下所示。 git checkout debian git-buildpackage -uc -us Debian环境下使用构建包安装GPG。 sudo apt-get install gnupg MAC平台安装git-crypt、GPG macOS上安装git-crypt。 使用 brew 软件包管理器，只需运行如下命令。 brew install git-crypt macOS上安装GPG。 使用 brew 软件包管理器，只需运行如下命令。 brew install GPG

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

设置检视意见 根据需要选择是否勾选“启用检视意见分类与模块”启用检视意见。 配置检视意见分类。 启用系统预置检视意见分类 勾选“启用系统预置检视意见分类”，可直接使用系统预置检视意见分类。 自定义分类 支持自定义检视意见分类，输入类型名称，按Enter键保存。 请输入分类名称，按Enter键结束；名称中不可包含英文冒号，可用英文逗号分隔，上限为200字符；个数上限为20 ,不可重复。 在“检视意见模块设置”下输入框输入“类型名称”。 请输入模块名称，按Enter键结束；上限为200字符；可用英文逗号分隔，个数上限为20, 不可重复。 根据自己的需要勾选“启用新建/编辑检视意见时必填字段校验”。 单击“提交”，保存设置。 当您的检视意见包含敏感词汇或者图片，其中，词汇包括中文和英文语法，单击“新建检视意见”后跳转到检视意见页面，显示“审核不通过”，如果不及时修改，该条检视意见仅项目内成员可见。其他成员在此检视意见界面将看到“内容敏感，不予展示。”

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

如何使用标签找回历史版本 当您要查看某个标签指向版本的代码时，可以将其检出到工作区。由于被检出的版本仅隶属于标签，而不属于任何分支，因此该代码可以编辑，但是不能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命令以完成您在特定场景下需要的操作，不建议全流程直接复制使用。

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

基于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分支是主要分支，并且都是唯一的，其它派生分支每个类型可以同时存在多个。