提交 a0479f0b 编写于 作者: M miykael

remove html

上级 44ad694e

要显示的变更太多。

To preserve performance only 1000 of 1000+ files are displayed.
此差异已折叠。
# 项目[](#项目 "Permalink")
您可以创建用于托管代码库的项目,可以通过项目进行 Issue 管理,进行代码协作,并使用内置的 CI / CD 持续构建,测试和部署应用程序。
您可以设置您的项目为[公开](../../public_access/public_access.html)[私有](../../public_access/public_access.html),我们也不限制您创建的私有项目数量。
## 项目功能[](#项目功能 "Permalink")
创建项目时,您可以使用众多功能:
**代码仓库:**
* [Issue](issues/index.html) :与您的团队讨论问题内的实现
* [看板](issue_board.html) :组织工作流程并确定其优先级
* [代码仓库](repository/index.html) :将代码托管在完全集成的平台中
* [分支](repository/branches/index.html) :使用 Git 分支策略在代码上进行协作
* [受保护的分支机构](protected_branches.html) :防止协作者弄乱历史记录或在未经审查的情况下推送代码
* [受保护的标签](protected_tags.html) :控制谁有权创建标签,并防止意外更新或删除
* [储存库镜像](repository/repository_mirroring.html)
* [签署提交](gpg_signed_commits/index.html) :使用 GPG 签署您的提交
* [部署令牌](deploy_tokens/index.html) :管理基于项目的部署令牌,这些令牌允许永久访问存储库和 Container Registry.
* [Web IDE](web_ide/index.html)
**Release 及合并请求:**
* [Issue](issues/index.html) :与您的团队讨论问题内的实现
* [发行板](issue_board.html) :组织工作流程并确定其优先级
* [合并请求](merge_requests/index.html) :应用您的分支策略并获得团队的审查
* [合并请求批准](merge_requests/merge_request_approvals.html) :实施更改之前[请求批准](merge_requests/merge_request_approvals.html)
* [修复合并中的冲突](merge_requests/resolve_conflicts.html) :直接从网页中使用 Git diff 工具
* [审查应用程序](../../ci/review_apps/index.html) :按分支实时预览合并请求中建议的更改结果
* [标签](labels.html) :按标签整理问题并合并请求
* [时间跟踪](time_tracking.html) :跟踪估计在完成问题或合并请求上花费的时间和时间
* [里程碑](milestones/index.html) :朝着目标日期迈进
* [描述模板](description_templates.html) :为项目定义特定于上下文的模板,并为您的项目合并请求描述字段
* [斜杠命令(快速操作)](quick_actions.html) :针对问题或合并请求的常见操作的文本快捷方式
* [自动完成字符](autocomplete_characters.html) :自动完成对用户,组,问题,合并请求和其他 GitLab 元素的引用.
* [Web IDE](web_ide/index.html)
**亚搏体育 app CI / CD:**
* [GitLab CI / CD](../../ci/README.html) :GitLab 内置的[持续集成,交付和部署](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/)工具
* [容器注册表](../packages/container_registry/index.html) :开箱即用地构建和推送 Docker 映像
* [自动部署](../../topics/autodevops/stages.html#auto-deploy) :配置 GitLab CI / CD 以自动设置应用程序的部署
* [启用和禁用 GitLab CI / CD](../../ci/enable_or_disable_ci.html)
* [管道](../../ci/pipelines/index.html) :从 UI 配置和可视化 GitLab CI / CD 管道
* [计划的管道](../../ci/pipelines/schedules.html) :计划管道以在选定的时间开始
* [管道图](../../ci/pipelines/index.html#visualize-pipelines) :通过 UI 查看整个管道
* [作业工件](../../ci/pipelines/job_artifacts.html) :定义,浏览和下载作业工件
* [管道设置](../../ci/pipelines/settings.html) :设置 Git 策略(选择从作业中的 GitLab 提取存储库的默认方式),超时(定义可以运行作业的最长时间(以分钟为`.gitlab-ci.yml` )) `.gitlab-ci.yml`自定义路径,测试覆盖率分析,管道的可见性等
* [Kubernetes 集群集成](clusters/index.html) :将您的 GitLab 项目与 Kubernetes 集群连接
* [功能标志](../../operations/feature_flags.html) :功能标志允许您通过动态切换某些功能来以不同的方式发布项目
* [GitLab Pages](pages/index.html) :使用[GitLab Pages](pages/index.html)构建,测试和部署您的静态网站
**其他特性:**
* [Wiki](wiki/index.html) :在集成的 Wiki 中记录您的 GitLab 项目.
* [片段](../snippets.html) :存储,共享和协作代码片段.
* [价值流分析](cycle_analytics.html) :查看您的开发生命周期.
* [见解](insights/index.html) :配置对您的项目至关重要的见解.
* [安全仪表板](security_dashboard.html) :安全仪表板.
* [语法突出显示](highlighting.html) :一种自定义代码块的替代方法,它替代了 GitLab 的默认语言选择.
* [徽章](badges.html) :项目概述的徽章.
* [发行版](releases/index.html) :一种跟踪项目中可交付成果的方式,可作为源,构建输出,其他元数据和与代码的发行版本相关的其他工件的快照.
* [Conan 软件包](../packages/conan_repository/index.html) :您在 GitLab 中的私人 Conan 存储库.
* [Maven 软件包](../packages/maven_repository/index.html) :您在 GitLab 中的私有 Maven 存储库.
* [NPM 软件包](../packages/npm_registry/index.html) :您在 GitLab 中的私有 NPM 软件包注册表.
* [代码所有者](code_owners.html) :为某些文件指定代码所有者
* [许可证合规性](../compliance/license_compliance/index.html) :批准和拒绝项目的许可证.
* [依赖项列表](../application_security/dependency_list/index.html) :查看项目依赖项.
* [要求](requirements/index.html) :要求使您可以创建标准来检查产品.
* [静态站点编辑器](static_site_editor/index.html) :无需事先了解代码库或 Git 命令,即可在静态网站上快速编辑内容.
* [代码智能](code_intelligence.html) :代码导航功能.
### Project integrations[](#project-integrations "Permalink")
[将您的项目](integrations/index.html)与 Jira,Mattermost,Kubernetes,Slack 等进行[集成](integrations/index.html) .
## New project[](#new-project "Permalink")
了解如何在 GitLab 中[创建一个新项目](../../gitlab-basics/create-project.html) .
### Fork a project[](#fork-a-project "Permalink")
您可以[派生一个项目](repository/forking_workflow.html) ,以便:
* 通过分叉项目并创建从分支到上游项目的合并请求来进行代码协作
* 分叉一个示例项目以在其顶部工作
### Star a project[](#star-a-project "Permalink")
您可以为项目加注星标,以使其更容易找到您经常使用的项目. 项目拥有的明星数量可以表明其受欢迎程度.
为项目加注星标:
1. 转到要加注星标的项目的主页.
2. 在页面的右上角,点击**星标** .
要查看已加星标的项目,请执行以下操作:
1. 单击导航栏中的**项目** .
2. Click **已加星标的项目**.
3. GitLab 显示有关已加星标项目的信息,包括:
* 项目描述,包括名称,描述和图标
* 已为该项目加注星标的次数
* Number of times this project has been forked
* 打开的合并请求数
* 未解决问题的数量
### Explore projects[](#explore-projects "Permalink")
您可以探索 GitLab 上可用的其他流行项目. 探索项目:
1. 单击导航栏中的**项目** .
2. Click **探索项目**.
GitLab 显示一个项目列表,按上次更新日期排序. 要查看具有最多[星星的](#star-a-project)项目,请单击" **最多星星"** . 要查看过去一个月中评论数量最多的项目,请点击**趋势** .
## Project settings[](#project-settings "Permalink")
将项目的可见性级别和访问级别设置为各个页面,并执行诸如归档,重命名或传输项目的操作.
通读有关[项目设置](settings/index.html)的文档.
## Import or export a project[](#import-or-export-a-project "Permalink")
* [Import a project](import/index.html) from:
* [GitHub to GitLab](import/github.html)
* [Bitbucket to GitLab](import/bitbucket.html)
* [Gitea to GitLab](import/gitea.html)
* [FogBugz to GitLab](import/fogbugz.html)
* [Export a project from GitLab](settings/import_export.html#exporting-a-project-and-its-data)
* [Importing and exporting projects between GitLab instances](settings/import_export.html)
## Remove a project[](#remove-a-project "Permalink")
要删除项目,请首先导航到该项目的主页.
1. 导航至**设置>常规** .
2. 展开**高级**部分.
3. 向下滚动到" **删除项目"**部分.
4. Click **移除专案**
5. 通过输入所需的文本来确认此操作.
### Delayed removal[](#delayed-removal-premium "Permalink")
默认情况下,单击以删除项目后会延迟 7 天. 管理员可以在这段时间内恢复项目. [管理员可以更改](../admin_area/settings/visibility_and_access_controls.html#default-deletion-adjourned-period-premium-only)此延迟.
管理员可以查看所有待删除项目. 如果您是管理员,请转到顶部导航栏,单击" **项目">"您的项目"** ,然后选择"已**删除的项目"**选项卡. 管理员可以从此选项卡还原任何项目.
## CI/CD for external repositories[](#cicd-for-external-repositories-premium "Permalink")
您可以将存储库作为 CI / CD 项目连接,而不是将存储库直接导入到 GitLab.
通读[CI / CD 上有关外部存储库](../../ci/ci_cd_for_external_repos/index.html)的文档.
## Project members[](#project-members "Permalink")
了解如何[将成员添加到您的项目中](members/index.html) .
## Project activity[](#project-activity "Permalink")
要查看项目的活动,请导航至**项目概述>活动** . 在此处,您可以单击选项卡以查看**所有**活动,或查看按**Push 事件****Merge 事件****Issue 事件****Comment****Team****Wiki**过滤的**活动** .
### Leave a project[](#leave-a-project "Permalink")
当项目属于组时(在[组命名空间下](../group/index.html#namespaces) ), **离开项目**将仅显示在项目的仪表板上. 如果您选择退出项目,那么您将不再是项目成员,因此无法参与.
## Project’s landing page[](#projects-landing-page "Permalink")
项目的登录页面根据项目的可见性设置和用户权限显示不同的信息.
对于公共项目以及[有权查看该项目代码](../permissions.html#project-members-permissions)的内部和私有项目的成员:
* 显示[`README`文件或索引文件的](repository/#repository-readme-and-index-files)内容(如果有),然后显示项目存储库中的目录列表.
* 如果项目不包含这些文件中的任何一个,则访问者将看到存储库的文件和目录列表.
对于没有权限查看项目代码的用户:
* 显示维基主页(如果有).
* 显示项目中的问题列表.
## Redirects when changing repository paths[](#redirects-when-changing-repository-paths "Permalink")
当存储库路径更改时,从旧位置平稳过渡到新位置至关重要. GitLab 提供两种重定向:Web UI 和 Git 推/拉重定向.
根据情况,可能会有所不同.
When [renaming a user](../profile/index.html#changing-your-username), [changing a group path](../group/index.html#changing-a-groups-path) or [renaming a repository](settings/index.html#renaming-a-repository):
* 名称空间及其下的任何内容(例如项目)的现有 Web URL 将重定向到新 URL.
* 从 GitLab 10.3 开始,命名空间下项目的现有 Git 远程 URL 将重定向到新的远程 URL. 每次将其推/拉到更改位置的存储库时,都会显示一条警告消息,提示您更新遥控器,而不是拒绝操作. 这意味着在重命名后,任何自动化脚本或 Git 客户端将继续工作,从而使任何过渡都更加顺畅.
* The redirects will be available as long as the original path is not claimed by another group, user or project.
## Use your project as a Go package[](#use-your-project-as-a-go-package "Permalink")
任何项目都可以用作 Go 包. GitLab 会正确响应`go get``godoc.org`发现请求,包括[`go-import`](https://s0golang0org.icopy.site/cmd/go/)[`go-source`](https://github.com/golang/gddo/wiki/Source-Code-Links)元标记.
私有项目(包括子组中的项目)可以用作 Go 包,但可能需要进行配置才能正常工作. 无论身份验证或授权如何,GitLab 都会正确响应以`go get` *不在*子组中的项目的发现请求. 要使用子组中的私有项目作为 Go 包,必须进行[身份验证](#authenticate-go-requests) . 否则,GitLab 会将子组中私有项目的路径截断到前两个段,从而导致`go get`失败.
GitLab 实现了自己的 Go 代理. 此功能必须由管理员启用,并且需要其他配置. 请参阅[GitLab Go 代理](../packages/go_proxy/index.html) .
### Disable Go module features for private projects[](#disable-go-module-features-for-private-projects "Permalink")
In Go 1.12 and later, Go queries module proxies and checksum databases in the process of [fetching a module](../../development/go_guide/dependencies.html#fetching). This can be selectively disabled with `GOPRIVATE` (disable both), [`GONOPROXY`](../../development/go_guide/dependencies.html#proxies) (disable proxy queries), and [`GONOSUMDB`](../../development/go_guide/dependencies.html#fetching) (disable checksum queries).
`GOPRIVATE``GONOPROXY``GONOSUMDB`是 Go 模块和 Go 模块前缀的逗号分隔列表. 例如, `GOPRIVATE=gitlab.example.com/my/private/project`将禁用对该项目的查询,而`GOPRIVATE=gitlab.example.com`将禁用`GOPRIVATE=gitlab.example.com` *所有*项目的查询. 如果模块名称或其前缀出现在`GOPRIVATE``GONOPROXY` ,则 Go 不会查询模块代理. 如果模块名称或其前缀出现在`GONOPRIVATE``GONOSUMDB` ,则 Go 不会查询校验和数据库.
### Authenticate Go requests[](#authenticate-go-requests "Permalink")
要验证对 Go 私有项目的请求,请在密码字段中使用[`.netrc`文件](https://ec.haxx.se/usingcurl-netrc.html)[个人访问令牌](../profile/personal_access_tokens.html) . **仅当可以通过 HTTPS 访问您的 GitLab 实例时,此方法才有效.** `go`命令不会通过不安全的连接传输凭据. 这将验证 Go 直接发出的所有 HTTPS 请求,但不会验证通过 Git 发出的请求.
例如:
```
machine example.gitlab.com
login <gitlab_user_name>
password <personal_access_token>
```
**注意:**在 Windows 上,Go 读取`~/_netrc`而不是`~/.netrc` .
### Authenticate Git fetches[](#authenticate-git-fetches "Permalink")
如果无法从代理中获取模块,Go 将退回到使用 Git(对于 GitLab 项目). Git 将使用`.netrc`来认证请求. 另外,可以将 Git 配置为在请求 URL 中嵌入特定的凭据,或者使用 SSH 代替 HTTPS(因为 Go 始终使用 HTTPS 来获取 Git 存储库):
```
# embed credentials in any request to GitLab.com:
git config --global url."https://${user}:${personal_access_token}@gitlab.example.com".insteadOf "https://gitlab.example.com"
# use SSH instead of HTTPS:
git config --global url."git@gitlab.example.com".insteadOf "https://gitlab.example.com"
```
## Access project page with project ID[](#access-project-page-with-project-id "Permalink")
在 GitLab 11.8 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/53671) .
要使用项目 ID 从 GitLab UI 快速访问项目,请在浏览器或其他访问项目的工具中访问`/projects/:id` URL.
## Project aliases[](#project-aliases-premium-only "Permalink")
[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/3264) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.1.
将存储库迁移到 GitLab 并被其他系统访问时,能够使用相同的名称访问它们非常有用,尤其是当它们很多时. 它降低了在大量系统中更改大量 Git URL 的风险.
manbetx 客户端打不开提供了功能来帮助这一点. 在 GitLab 中,通常使用名称空间和项目名称访问存储库. 也可以通过项目别名访问它们. 此功能仅在通过 SSH 的 Git 上可用.
项目别名只能通过 API 创建,并且只能由 GitLab 管理员创建. 有关更多详细信息,请遵循[Project Aliases API 文档](../../api/project_aliases.html) .
一旦为项目创建了别名(例如,项目`https://gitlab.com/gitlab-org/gitlab`的别名`gitlab` ),就可以使用别名(例如`git clone git@gitlab.com:gitlab.git` )来克隆存储库. `git clone git@gitlab.com:gitlab.git`而不是`git clone git@gitlab.com:gitlab-org/gitlab.git` ).
## Project APIs[](#project-apis "Permalink")
您的项目可以使用许多[API](../../api/README.html)
* [Badges](../../api/project_badges.html)
* [Clusters](../../api/project_clusters.html)
* [Threads](../../api/discussions.html)
* [General](../../api/projects.html)
* [Import/export](../../api/project_import_export.html)
* [Issue Board](../../api/boards.html)
* [Labels](../../api/labels.html)
* [Markdown](../../api/markdown.html)
* [Merge Requests](../../api/merge_requests.html)
* [Milestones](../../api/milestones.html)
* [Services](../../api/services.html)
* [Snippets](../../api/project_snippets.html)
* [Templates](../../api/project_templates.html)
* [Traffic](../../api/project_statistics.html)
* [Variables](../../api/project_level_variables.html)
* [Aliases](../../api/project_aliases.html)
\ No newline at end of file
此差异已折叠。
# Security Configuration
> 原文:[https://docs.gitlab.com/ee/user/application_security/configuration/](https://docs.gitlab.com/ee/user/application_security/configuration/)
* [Overview](#overview)
* [Limitations](#limitations)
# Security Configuration[](#security-configuration-ultimate "Permalink")
[Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20711) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.6.
## Overview[](#overview "Permalink")
安全配置页面显示每个安全功能的配置状态,可以通过项目的侧边栏导航来访问.
[![Screenshot of security configuration page](img/c5fbd1d44b70c599ae2cc8751ccfca14.png)](../img/security_configuration_page_v13_2.png)
该页面使用项目的最新默认分支[CI 管道](../../../ci/pipelines/index.html)来确定每个功能部件的配置状态. 如果管道中存在具有预期安全报告工件的作业,则认为该功能已配置.
**注意:**如果最新的管道使用了[Auto DevOps](../../../topics/autodevops/index.html) ,则默认情况下将配置所有安全功能.
## Limitations[](#limitations "Permalink")
尚无法使用配置页启用或禁用大多数功能. 但是,可以通过该页面上每个功能旁边的链接找到有关如何启用或禁用功能的说明.
如果项目没有现有的 CI 配置,则可以通过单击"管理"列下的"启用合并请求"按钮来启用 SAST 功能. 将来的工作会将其扩展到编辑*现有* CI 配置以及其他安全功能.
\ No newline at end of file
此差异已折叠。
此差异已折叠。
# Dependency List
> 原文:[https://docs.gitlab.com/ee/user/application_security/dependency_list/](https://docs.gitlab.com/ee/user/application_security/dependency_list/)
* [Requirements](#requirements)
* [Viewing dependencies](#viewing-dependencies)
* [Vulnerabilities](#vulnerabilities)
* [Licenses](#licenses)
* [Downloading the Dependency List](#downloading-the-dependency-list)
# Dependency List[](#dependency-list-ultimate "Permalink")
[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10075) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.0.
"依赖关系"列表使您可以查看项目的依赖关系以及有关它们的关键详细信息,包括已知漏洞. 要查看它,请导航至项目侧栏中的" **安全性和合规性">"依赖项列表"** . 该信息有时被称为软件物料清单或 SBoM / BOM.
## Requirements[](#requirements "Permalink")
1. 必须为您的项目配置" [依赖项扫描](../dependency_scanning/index.html) CI"作业.
2. 您的项目至少使用 Gemnasium 支持的一种[语言和包管理器](../dependency_scanning/index.html#supported-languages-and-package-managers) .
## Viewing dependencies[](#viewing-dependencies "Permalink")
[![Dependency List](img/e4fa52f4d522392d049bf73b1bb065a5.png)](img/dependency_list_v12_10.png)
依存关系显示以下信息:
| Field | Description |
| --- | --- |
| Component | 依赖项的名称和版本 |
| Packager | 打包程序用于安装依赖项 |
| Location | 指向项目中特定于包装程序的锁定文件的链接,该文件声明了依赖性 |
| License | 链接到依赖项的软件许可证 |
最初显示的依赖项是按其已知漏洞的严重性(如果有)进行排序的. 也可以按名称或安装它们的打包程序对它们进行排序.
### Vulnerabilities[](#vulnerabilities "Permalink")
如果依赖项具有已知漏洞,则可以通过单击依赖项名称旁边的箭头或指示存在多少已知漏洞的标志来查看它们. 对于每个漏洞,其严重性和描述将显示在其下方.
## Licenses[](#licenses "Permalink")
在 GitLab Ultimate 12.3 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/10536) .
如果配置了" [许可证合规性](../../compliance/license_compliance/index.html) CI"作业,则[发现的许可证](../../compliance/license_compliance/index.html#supported-languages-and-package-managers)将显示在此页面上.
## Downloading the Dependency List[](#downloading-the-dependency-list "Permalink")
您可以通过单击下载按钮以`JSON`格式下载项目的依赖关系及其详细信息的完整列表.
\ No newline at end of file
此差异已折叠。
# Secret Detection
> 原文:[https://docs.gitlab.com/ee/user/application_security/secret_detection/](https://docs.gitlab.com/ee/user/application_security/secret_detection/)
* [Overview](#overview)
* [Use cases](#use-cases)
* [Requirements](#requirements)
* [Configuration](#configuration)
* [Using the SAST Template](#using-the-sast-template)
* [Customizing settings](#customizing-settings)
* [Available variables](#available-variables)
* [Logging Level](#logging-level)
* [Full History Secret Scan](#full-history-secret-scan)
# Secret Detection[](#secret-detection-ultimate "Permalink")
[Introduced](https://about.gitlab.com/releases/2019/03/22/gitlab-11-9-released/#detect-secrets-and-credentials-in-the-repository) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.9.
## Overview[](#overview "Permalink")
开发应用程序时经常出现的问题是,开发人员可能会无意间将秘密和凭据提交到其远程存储库. 如果其他人可以访问源,或者项目是公开的,则敏感信息将被公开,恶意用户可以利用这些信息来访问诸如部署环境之类的资源.
GitLab 11.9 包含一个称为"秘密检测"的新检查. 它扫描存储库的内容以查找 API 密钥和其他不应存在的信息.
manbetx 客户端打不开显示识别的秘密作为 SAST 报告的一部分在几个地方:
* [Security Dashboard](../security_dashboard/)
* Pipelines’ **Security** tab
* 合并请求小部件中的报告
[![Secret Detection in merge request widget](img/56321b27a391110651e26fae3d93064e.png)](img/secret_detection_v13_2.png)
## Use cases[](#use-cases "Permalink")
* 检测密钥,密码和 API 令牌等机密信息的意外提交.
* 对存储库的完整历史记录执行一次或重复扫描以查找机密信息.
## Requirements[](#requirements "Permalink")
要运行检测的秘密工作,默认情况下,你需要 GitLab 亚军与[`docker`](https://docs.gitlab.com/runner/executors/docker.html)[`kubernetes`](https://docs.gitlab.com/runner/install/kubernetes.html)执行. 如果您在 GitLab.com 上使用共享的 Runners,则默认启用该功能.
**注意:**目前我们的秘密检测作业需要 Linux 容器类型. Windows 容器尚不支持.**注意:**如果使用自己的 Runners,请确保安装的 Docker 版本**不是** `19.03.0` . 有关详细[信息](../sast#error-response-from-daemon-error-processing-tar-file-docker-tar-relocation-error) ,请参见[故障排除信息](../sast#error-response-from-daemon-error-processing-tar-file-docker-tar-relocation-error) .
## Configuration[](#configuration "Permalink")
**注意:**在 GitLab 13.1 中,秘密检测被拆分为自己的 CI / CD 模板.
秘密检测是在`secret-detection`作业期间由[特定的分析器](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/Secret-Detection.gitlab-ci.yml)执行的. 无论您的应用程序使用哪种编程语言,它都可以运行.
秘密检测分析器包括[Gitleaks](https://github.com/zricethezav/gitleaks)[TruffleHog](https://github.com/dxa4481/truffleHog)检查.
***Note:** The Secret Detection analyzer will ignore "Password in URL" vulnerabilities if the password begins with a dollar sign ( `$` ) as this likely indicates the password being used is an environment variable. **注意:**如果密码以美元符号( `$` )开头,则秘密检测分析器将忽略" URL 中的密码"漏洞,因为这很可能表明所使用的密码是环境变量. For example, `https://username:$password@example.com/path/to/repo` won't be detected, whereas `https://username:password@example.com/path/to/repo` would be detected. 例如,将不会检测到`https://username:$password@example.com/path/to/repo` ,而将检测到`https://username:password@example.com/path/to/repo` .***注意:**如果您使用的是[Auto DevOps](../../../topics/autodevops/index.html)提供的[自动](../../../topics/autodevops/index.html) [秘密检测,](../../../topics/autodevops/stages.html#auto-secret-detection-ultimate)则不必按照本节中的说明手动配置秘密检测.
要为 GitLab 13.1 和更高版本启用 Secret Detection,您必须包括`Secret-Detection.gitlab-ci.yml`模板,该模板作为 GitLab 安装的一部分提供. 对于 11.9 之前的 GitLab 版本,您可以复制和使用该模板中定义的作业.
将以下内容添加到您的`.gitlab-ci.yml`文件中:
```
include:
- template: Secret-Detection.gitlab-ci.yml
```
包含的模板在 CI / CD 管道中创建"秘密检测"作业,并扫描项目的源代码中的秘密.
结果将保存为" [秘密检测"报告工件](../../../ci/pipelines/job_artifacts.html#artifactsreportssecret_detection-ultimate) ,您以后可以下载和分析该[工件](../../../ci/pipelines/job_artifacts.html#artifactsreportssecret_detection-ultimate) . 由于实施限制,我们始终采用最新的秘密检测工件.
### Using the SAST Template[](#using-the-sast-template "Permalink")
在 GitLab 13.1 之前,秘密检测是[SAST 配置的](../sast#configuration)一部分. 如果您已经在 GitLab 13.1 之前为您的应用配置了启用 SAST,则无需手动配置它.
**计划的弃用:**在以后的 GitLab 版本中,将不建议使用 SAST 模板配置秘密检测. 请开始使用`Secret-Detection.gitlab-ci.yml`以防止将来出现问题. 我们制作了一个[视频,指导您完成过渡](https://www.youtube.com/watch?v=W2tjcQreDwQ)到此新模板的过程.观看视频: [历史秘密扫描演练](https://www.youtube.com/watch?v=W2tjcQreDwQ) .
<figure class="video-container"><iframe src="https://www.youtube.com/embed/W2tjcQreDwQ" frameborder="0" allowfullscreen=""></iframe></figure>
使用 SAST 模板时,秘密检测由[特定分析器](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml#L180)`sast`作业期间执行. 它的运行与应用程序的编程语言无关,并且您无需更改 CI / CD 配置文件即可启用它. 结果可在 SAST 报告中获得.
### Customizing settings[](#customizing-settings "Permalink")
可以使用`.gitlab-ci.yml`[`variables`](../../../ci/yaml/README.html#variables)参数通过[环境变量](#available-variables)更改秘密检测扫描设置.
要覆盖作业定义(例如,更改`variables``dependencies`类的属性),请声明与要覆盖的 SAST 作业同名的作业. 将此新作业放置在包含模板之后,并在其下指定其他任何键.
在下面的示例中,我们包括"秘密检测"模板,同时使用`SECRET_DETECTION_HISTORIC_SCAN`变量将`secret_detection`作业覆盖为`true`
```
include:
- template: Secret-Detection.gitlab-ci.yml
secret_detection:
variables:
SECRET_DETECTION_HISTORIC_SCAN: "true"
```
因为模板是[](../../../ci/yaml/README.html#include)管道配置[之前进行评估](../../../ci/yaml/README.html#include)的,所以最后提到的变量优先.
**弃用:**从 GitLab 13.0 开始,不再支持[`only`和`except`](../../../ci/yaml/README.html#onlyexcept-basic)的使用. 覆盖模板时,必须使用[`rules`](../../../ci/yaml/README.html#rules) .
#### Available variables[](#available-variables "Permalink")
可以通过定义可用变量来自定义秘密检测:
| 环境变量 | 默认值 | Description |
| --- | --- | --- |
| `SECRET_DETECTION_COMMIT_FROM` | - | 提交 Gitleaks 扫描始于. |
| `SECRET_DETECTION_COMMIT_TO` | - | Gitleaks 扫描的提交结束于. |
| `SECRET_DETECTION_HISTORIC_SCAN` | false | 标记以启用历史性的 Gitleaks 扫描. |
### Logging Level[](#logging-level "Permalink")
您可以通过设置`SECURE_LOG_LEVEL` env var 来控制日志的详细程度. 默认设置为`info` ,您可以将其设置为以下任意级别:
* `fatal`
* `error`
* `warn`
* `info`
* `debug`
## Full History Secret Scan[](#full-history-secret-scan "Permalink")
GitLab 12.11 引入了对扫描存储库完整历史记录的支持. 当您首次在存储库中启用秘密检测并且想要执行完整的秘密扫描时,此新功能特别有用. 对整个历史记录进行秘密扫描可能会花费很长时间,尤其是对于 Git 历史记录较长的大型存储库. 我们建议不要将此变量设置为常规作业定义的一部分.
可以设置一个新的配置变量( [`SECRET_DETECTION_HISTORIC_SCAN`](../sast/#vulnerability-filters) )来更改 GitLab 秘密检测扫描的行为,使其在存储库的整个 Git 历史记录上运行.
我们创建了一个[简短的视频演练,](https://youtu.be/wDtc_K00Y0A)展示了如何执行完整的历史秘密扫描.
观看视频: [历史秘密扫描演练](https://www.youtube.com/watch?v=wDtc_K00Y0A) .
<figure class="video-container"><iframe src="https://www.youtube.com/embed/wDtc_K00Y0A" frameborder="0" allowfullscreen=""></iframe></figure>
\ No newline at end of file
此差异已折叠。
# GitLab Security Dashboard
> 原文:[https://docs.gitlab.com/ee/user/application_security/security_dashboard/](https://docs.gitlab.com/ee/user/application_security/security_dashboard/)
* [Supported reports](#supported-reports)
* [Requirements](#requirements)
* [Pipeline Security](#pipeline-security)
* [Project Security Dashboard](#project-security-dashboard)
* [Group Security Dashboard](#group-security-dashboard)
* [Instance Security Dashboard](#instance-security-dashboard)
* [Adding projects to the dashboard](#adding-projects-to-the-dashboard)
* [Export vulnerabilities](#export-vulnerabilities)
* [Keeping the dashboards up to date](#keeping-the-dashboards-up-to-date)
* [Security scans using Auto DevOps](#security-scans-using-auto-devops)
* [Vulnerability list](#vulnerability-list)
# GitLab Security Dashboard[](#gitlab-security-dashboard-ultimate "Permalink")
在"安全仪表板"中,您可以概览您的组,项目和管道中的所有安全漏洞.
您还可以深入研究漏洞并获得更多信息,查看其来源,项目所在的文件以及各种元数据,以帮助您分析风险. 您也可以通过为漏洞创建问题或消除漏洞来对漏洞采取措施.
要从"安全仪表板"中受益,您必须首先配置其中一份[安全报告](../index.html) .
## Supported reports[](#supported-reports "Permalink")
安全仪表板支持以下报告:
* [Container Scanning](../container_scanning/index.html)
* [Dynamic Application Security Testing](../dast/index.html)
* [Dependency Scanning](../dependency_scanning/index.html)
* [Static Application Security Testing](../sast/index.html)
## Requirements[](#requirements "Permalink")
要使用实例,组,项目或管道安全性仪表板,请执行以下操作:
1. 组中的至少一个项目必须配置有至少一个[受支持的报告](#supported-reports) .
2. 配置的作业必须使用[新的`reports`语法](../../../ci/pipelines/job_artifacts.html#artifactsreports) .
3. 必须使用[GitLab Runner](https://docs.gitlab.com/runner/) 11.5 或更高版本. 如果您在 GitLab.com 上使用共享的 Runners,那么情况已经如此.
## Pipeline Security[](#pipeline-security "Permalink")
[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/13496) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.3.
在管道级别,"安全性"部分显示了运行管道所针对的项目分支中存在的漏洞.
访问页面以查看运行了任何[受支持报告的](#supported-reports)任何管道. 单击**安全性**选项卡以查看安全性发现.
[![Pipeline Security Dashboard](img/f0d8585fb8235b36b1464ed1d142a4c0.png)](img/pipeline_security_dashboard_v13_2.png)
**注意:**管道包含多个作业,包括 SAST 和 DAST 扫描. 如果任何作业由于任何原因无法完成,则安全信息中心将不会显示 SAST 扫描仪输出. 例如,如果 SAST 作业完成但 DAST 作业失败,则安全性仪表板将不会显示 SAST 结果. 分析器将在失败时输出[退出代码](../../../development/integrations/secure.html#exit-code) .
## Project Security Dashboard[](#project-security-dashboard "Permalink")
[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/6165) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.1.
在项目级别,安全性仪表板显示合并到项目的[默认分支中](../../project/repository/branches/index.html#default-branch)的漏洞. 通过导航到" **安全与合规性">"安全仪表板"**来访问它.
安全仪表板首先按严重性显示漏洞的总数(例如,严重,高,中,低). 在此下方,有一个表显示每个漏洞的状态,严重性和描述. 单击漏洞会将您带到其" [漏洞详细信息"](../vulnerabilities)页面,以查看有关该漏洞的更多信息.
您可以通过以下方式过滤漏洞:
* Status
* Severity
* 报告类型
您还可以消除表中的漏洞:
1. 选择要消除的每个漏洞的复选框.
2. 在出现的菜单中,选择**退出**的原因,然后点击**取消选中** .
[![Project Security Dashboard](img/2066156f84e498acec96cdfb63d2d2a4.png)](img/project_security_dashboard_v13_2.png)
## Group Security Dashboard[](#group-security-dashboard "Permalink")
[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/6709) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.5.
组安全仪表板概述了组及其子组中项目的默认分支中的漏洞. 通过导航至组的" **安全性">"安全性仪表板"**来访问它.
**注意:** "安全仪表板"仅显示在组中启用了[安全报告的](#supported-reports)项目.
[![Dashboard with action buttons and metrics](img/7b7c08f411e1307c05a834071bccb610.png)](img/group_security_dashboard_v13_2_noNav.png)
您可以通过以下方式过滤安全仪表板显示的漏洞:
* Status
* Severity
* 报告类型
* Project
表格列出了漏洞,并按严重性排序. 该表显示了每个漏洞的状态,严重性和描述. 单击漏洞会将您带到其" [漏洞详细信息"](../vulnerabilities)页面,以查看有关该漏洞的更多信息.
列表旁边是时间线图,该图显示了您的项目在不同时间点有多少个未解决的漏洞. 您可以在 30 天,60 天和 90 天之间进行过滤,默认值为 90 天.将鼠标悬停在图表上可获得有关特定时间未解决漏洞的更多详细信息.
时间线图表下方是项目列表,按发现的漏洞的严重程度进行分组和排序:
* F:1 个或更多"关键"
* D:1 个或多个"高"或"未知"
* C: 1 or more “medium”
* B:1 个或多个"低"
* 答:0 个漏洞
未配置漏洞测试的项目不会出现在列表中. 此外,也不包含已消除的漏洞.
阅读有关如何[与漏洞](../index.html#interacting-with-the-vulnerabilities)进行[交互的](../index.html#interacting-with-the-vulnerabilities)更多信息.
## Instance Security Dashboard[](#instance-security-dashboard "Permalink")
[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/6953) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.8.
在实例级别,安全仪表板显示您配置为显示在仪表板上的所有项目的默认分支中存在的漏洞. 它包括[组"安全仪表板"的](#group-security-dashboard)所有功能.
您可以从页面顶部的菜单栏中访问 Instance Security 仪表板. 在" **更多"下** ,选择" **安全性"** .
[![Instance Security Dashboard navigation link](img/25892ec4aa99429a91c30ac3395379e0.png)](img/instance_security_dashboard_link_v12_4.png)
### Adding projects to the dashboard[](#adding-projects-to-the-dashboard "Permalink")
要将项目添加到仪表板:
1. 单击"实例安全性仪表板"页面上的**编辑仪表板**按钮.
2. 使用" **搜索您的项目"**字段搜索并添加一个或多个项目.
3. 单击**添加项目**按钮.
添加后,安全仪表板将显示在所选项目的默认分支中发现的漏洞.
[![Instance Security Dashboard with projects](img/5653420f4acd0e8a49be80d5d413bd10.png)](img/instance_security_dashboard_with_projects_v13_2_sm.png)
## Export vulnerabilities[](#export-vulnerabilities "Permalink")
[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/213014) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.10.
您可以通过以下方式将所有漏洞导出为 CSV 格式: 位于**安全仪表板**右上方的" **导出"**按钮. 生成报告后,CSV 报告将下载到本地计算机. 该报告包含" **安全性仪表板"中**定义的项目的所有漏洞,因为过滤器不适用于导出功能.
**注意:**如果您的项目包含成千上万个漏洞,下载可能需要几分钟的时间才能开始. 下载完成之前,请不要关闭页面.
## Keeping the dashboards up to date[](#keeping-the-dashboards-up-to-date "Permalink")
安全仪表板在[默认分支](../../project/repository/branches/index.html#default-branch)上显示来自最新安全扫描结果的信息,这意味着每次更新分支时都会执行安全扫描.
如果不经常更新默认分支,则不经常运行扫描,并且随着发现新漏洞,安全仪表板上的信息可能会过时.
为确保安全仪表板上的信息得到定期更新,请[配置计划的管道](../../../ci/pipelines/schedules.html)以运行每日安全扫描. 不管默认分支的更新频率如何,这都会更新"安全性"仪表板上显示的信息.
这样,即使没有代码更改也不会创建报告.
## Security scans using Auto DevOps[](#security-scans-using-auto-devops "Permalink")
使用[Auto DevOps 时](../../../topics/autodevops/index.html) ,请使用[特殊的环境变量](../../../topics/autodevops/customize.html#environment-variables)来配置每日安全扫描.
## Vulnerability list[](#vulnerability-list "Permalink")
Each dashboard’s vulnerability list contains vulnerabilities from the latest scans that were merged into the default branch. Click any vulnerability in the table to see more information on that vulnerability. To create an issue associated with the vulnerability, click the **创建问题** button.
[![Create an issue for the vulnerability](img/a9880855e171e225a4b6c73ae1790538.png)](img/standalone_vulnerability_page_v13_1.png)
创建问题后,漏洞列表将包含该问题的链接和一个图标,其颜色指示该问题的状态(绿色代表未解决的问题,蓝色代表未解决的问题).
[![Display attached issues](img/f1e26381a4d60fa929a9285e04721656.png)](img/vulnerability_list_table_v13_1.png)
\ No newline at end of file
# Offline environments
> 原文:[https://docs.gitlab.com/ee/user/application_security/offline_deployments/](https://docs.gitlab.com/ee/user/application_security/offline_deployments/)
* [Defining offline environments](#defining-offline-environments)
* [Overview](#overview)
* [Container registries and package repositories](#container-registries-and-package-repositories)
* [Interacting with the vulnerabilities](#interacting-with-the-vulnerabilities)
* [Suggested Solutions for vulnerabilities](#suggested-solutions-for-vulnerabilities)
* [Scanner signature and rule updates](#scanner-signature-and-rule-updates)
* [Specific scanner instructions](#specific-scanner-instructions)
# Offline environments[](#offline-environments "Permalink")
未连接到互联网时,可以运行大多数的 GitLab 安全扫描程序.
本文档介绍了如何在脱机环境中操作安全类别(即扫描仪类型). 这些说明还适用于受保护,具有安全策略(例如,防火墙策略)或受其他限制而无法访问整个 Internet 的自我管理安装. GitLab 将这些环境称为*脱机环境* . 其他常用名称包括:
* 气隙环境
* 受限的连接环境
* 局域网(LAN)环境
* 内联网环境
这些环境具有阻止或限制 Internet 访问的物理障碍或安全策略(例如,防火墙). 这些说明是为物理上断开连接的网络而设计的,但在其他用例中也可以遵循这些说明.
## Defining offline environments[](#defining-offline-environments "Permalink")
在离线环境中,GitLab 实例可以是一个或多个服务器和服务,它们可以在本地网络上进行通信,但是对 Internet 的访问没有限制或受到非常严格的限制. 假设可以通过本地网络连接访问 GitLab 实例和支持基础结构(例如,私有 Maven 存储库)中的任何内容. 假定来自 Internet 的任何文件都必须通过物理媒体(USB 驱动器,硬盘驱动器,可写 DVD 等)进入.
## Overview[](#overview "Permalink")
GitLab 扫描仪通常会连接到互联网,以下载最新的签名,规则和补丁集. 通过使用本地网络上可用的资源,需要一些额外的步骤来配置工具以使其正常运行.
### Container registries and package repositories[](#container-registries-and-package-repositories "Permalink")
在较高级别,安全分析器以 Docker 映像的形式提供,并且可以利用各种软件包存储库. 当您在联网的 GitLab 安装上运行作业时,GitLab 会检查 GitLab.com 托管的容器注册表,以检查您是否具有这些 Docker 映像的最新版本,并可能连接到软件包存储库以安装必要的依赖项.
在离线环境中,必须禁用这些检查,以便不查询 GitLab.com. 由于 GitLab.com 注册表和存储库不可用,因此您必须更新每个扫描仪以引用不同的内部托管注册表,或提供对单个扫描仪图像的访问.
您还必须确保您的应用可以访问不在 GitLab.com 上托管的常见软件包存储库,例如 npm,yarn 或 Ruby gems. 可以通过临时连接到网络或通过镜像自己的脱机网络中的软件包来获取这些存储库中的软件包.
### Interacting with the vulnerabilities[](#interacting-with-the-vulnerabilities "Permalink")
一旦发现漏洞,便可以与其进行交互. 阅读有关如何[与漏洞](../index.html#interacting-with-the-vulnerabilities)进行[交互的](../index.html#interacting-with-the-vulnerabilities)更多信息.
请注意,在某些情况下,所报告的漏洞提供的元数据可能包含 UI 中公开的外部链接. 在脱机环境中可能无法访问这些链接.
### Suggested Solutions for vulnerabilities[](#suggested-solutions-for-vulnerabilities "Permalink")
[建议的解决方案](../index.html#solutions-for-vulnerabilities-auto-remediation)功能(自动修复)可用于"依赖关系扫描"和"容器扫描",但可能无法运行,具体取决于实例的配置. 当我们能够访问托管该依赖项或映像的最新版本的最新注册表服务时,我们只能建议解决方案,这些解决方案通常是已修补的最新版本.
### Scanner signature and rule updates[](#scanner-signature-and-rule-updates "Permalink")
连接到 Internet 时,某些扫描仪会参考公共数据库以获取最新的签名集和要检查的规则. 没有连接,这是不可能的. 因此,根据扫描仪的不同,您必须禁用这些自动更新检查,并使用它们随附的数据库并手动更新这些数据库,或者提供对网络中托管的自己的副本的访问权限.
## Specific scanner instructions[](#specific-scanner-instructions "Permalink")
每个单独的扫描仪可能与上述步骤略有不同. 您可以在以下每个页面上找到更多信息:
* [Container scanning offline directions](../container_scanning/index.html#running-container-scanning-in-an-offline-environment)
* [SAST offline directions](../sast/index.html#running-sast-in-an-offline-environment)
* [DAST offline directions](../dast/index.html#running-dast-in-an-offline-environment)
* [License Compliance offline directions](../../compliance/license_compliance/index.html#running-license-compliance-in-an-offline-environment)
* [Dependency Scanning offline directions](../dependency_scanning/index.html#running-dependency-scanning-in-an-offline-environment)
\ No newline at end of file
# Standalone Vulnerability pages
> 原文:[https://docs.gitlab.com/ee/user/application_security/vulnerabilities/](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/)
* [Changing vulnerability status](#changing-vulnerability-status)
* [Creating an issue for a vulnerability](#creating-an-issue-for-a-vulnerability)
* [Automatic remediation solutions for vulnerabilities](#automatic-remediation-solutions-for-vulnerabilities)
* [Manually applying a suggested patch](#manually-applying-a-suggested-patch)
# Standalone Vulnerability pages[](#standalone-vulnerability-pages "Permalink")
[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/13561) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 13.0.
[安全仪表板](../security_dashboard/index.html#project-security-dashboard)中的每个安全漏洞都有其自己的独立页面.
[![Standalone vulnerability page](img/62d2b5c8435d31dff0a7fc689c288e8c.png)](img/standalone_vulnerability_page_v13_1.png)
在独立漏洞页面上,您可以通过几种不同方式与漏洞进行交互:
* [变化的脆弱性状态](#changing-vulnerability-status) -您可以将漏洞的状态更改为**检测****确认****驳回****解决** .
* [创建问题](#creating-an-issue-for-a-vulnerability) -创建一个新问题,其标题和说明已预先填充了漏洞报告中的信息. 默认情况下,此类问题是[机密的](../../project/issues/confidential_issues.html) .
* [解决方案](#automatic-remediation-solutions-for-vulnerabilities) -对于某些漏洞,提供了有关如何修复该漏洞的解决方案.
## Changing vulnerability status[](#changing-vulnerability-status "Permalink")
您可以使用" **状态"**下拉列表将漏洞的**状态**切换为以下值之一:
| Status | Description |
| --- | --- |
| Detected | 新发现漏洞的默认状态 |
| Confirmed | 用户已经看到此漏洞并确认它是真实的 |
| Dismissed | 用户已经看到此漏洞并将其消除 |
| Resolved | 该漏洞已修复,不再存在于代码库中 |
## Creating an issue for a vulnerability[](#creating-an-issue-for-a-vulnerability "Permalink")
您可以通过选择**创建问题**按钮来**创建**漏洞**问题** .
这会在漏洞来自的项目中创建一个[机密问题](../../project/issues/confidential_issues.html) ,并使用漏洞报告中的有用信息对其进行预填充. 创建问题后,GitLab 会将您重定向到问题页面,以便您可以编辑,分配或评论问题.
## Automatic remediation solutions for vulnerabilities[](#automatic-remediation-solutions-for-vulnerabilities "Permalink")
您可以通过应用 GitLab 为您自动生成的解决方案来修复某些漏洞. GitLab 支持以下扫描仪:
* [依赖项扫描](../dependency_scanning/index.html) :自动补丁创建仅适用于使用`yarn`管理的 Node.js 项目.
* [Container Scanning](../container_scanning/index.html).
When an automatic solution is available, the button in the header will show “Resolve with merge request”:
[![Resolve with Merge Request button](img/e661a6c6931c39f12f5b6833566b8947.png)](img/standalone_vulnerability_page_merge_request_button_v13_1.png)
选择该按钮将创建带有自动解决方案的合并请求.
### Manually applying a suggested patch[](#manually-applying-a-suggested-patch "Permalink")
要手动应用由 GitLab 生成的漏洞补丁,请选择"使用合并请求解决"按钮上的下拉箭头,然后选择"下载要解决的补丁"选项:
[![Resolve with Merge Request button dropdown](img/2310ec0a03905adc0774d21079604b57.png)](img/standalone_vulnerability_page_merge_request_button_dropdown_v13_1.png)
这会将按钮文本更改为"下载修补程序以解决". 单击它下载补丁:
[![Download patch button](img/4e980984ef171e4c624f56ebeb3277c7.png)](img/standalone_vulnerability_page_download_patch_button_v13_1.png)
\ No newline at end of file
此差异已折叠。
# Badges
> 原文:[https://docs.gitlab.com/ee/user/project/badges.html](https://docs.gitlab.com/ee/user/project/badges.html)
* [Project badges](#project-badges)
* [Group badges](#group-badges)
* [Placeholders](#placeholders)
* [API](#api)
# Badges[](#badges "Permalink")
在 GitLab 10.7 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/41174) .
徽章是呈现有关您的项目的简要信息的统一方法. 它们由一个小图像以及该图像指向的 URL 组成. 徽章的示例可以是[管道状态](../../ci/pipelines/settings.html#pipeline-status-badge)[测试范围](../../ci/pipelines/settings.html#test-coverage-report-badge)或与项目维护者联系的方式.
[![Badges on Project overview page](img/0e0e78d03e98ec2ac04952defaba83ff.png)](img/project_overview_badges.png)
## Project badges[](#project-badges "Permalink")
维护者或所有者可以将徽章添加到项目中,然后在项目的概述页面上可见. 如果发现必须将相同的徽标添加到多个项目,则可能需要在[组级别](#group-badges)添加它们.
要将新徽章添加到项目:
1. 导航到项目的**设置>常规>徽章** .
2. 在"链接"下,输入徽章应指向的 URL,在"徽章图像 URL"下输入应显示的图像的 URL.
3. 通过单击**添加徽章**按钮来提交**徽章** .
将徽章添加到项目后,您可以在表单下方的列表中看到它. 您可以通过单击旁边的笔图标进行编辑,也可以通过单击垃圾箱图标将其删除.
与组关联的徽章只能在[组级别](#group-badges)上进行编辑或删除.
## Group badges[](#group-badges "Permalink")
可以将徽章添加到组中,然后将在该组下的每个项目的概述页面上看到它们. 在这种情况下,无法在项目级别上对其进行编辑或删除. 如果每个项目需要单独的徽章,请考虑将其添加到[项目级别](#project-badges)或使用[占位符](#placeholders) .
要将新徽章添加到组:
1. 导航到组的**"设置">"常规">"徽章"** .
2. 在"链接"下,输入徽章应指向的 URL,在"徽章图像 URL"下输入应显示的图像的 URL.
3. 通过单击**添加徽章**按钮来提交**徽章** .
将徽章添加到组后,您可以在表格下方的列表中看到它. 您可以通过单击徽章旁边的笔图标来编辑徽章,也可以通过单击垃圾箱图标来删除徽章.
与项目直接关联的徽章可以在[项目级别](#project-badges)上配置.
## Placeholders[](#placeholders "Permalink")
徽章指向的 URL 以及图像 URL 可以包含占位符,在显示徽章时将对其进行评估. 可以使用以下占位符:
* `%{project_path}` :包含父组的项目的路径
* `%{project_id}` :与项目关联的数据库 ID
* `%{default_branch}` :为项目存储库配置的默认分支名称
* `%{commit_sha}` :对项目存储库的默认分支的最新提交的 ID
**Note:** Placeholders allow badges to expose otherwise-private information, such as the default branch or commit SHA when the project is configured to have a private repository. This is by design, as badges are intended to be used publicly. Avoid using these placeholders if the information is sensitive.
## API[](#api "Permalink")
您还可以通过 GitLab API 配置徽章. 与设置一样,在[项目级别](../../api/project_badges.html)[组级别的](../../api/group_badges.html)徽章端点之间也有所区别.
\ No newline at end of file
# Bulk editing issues and merge requests at the project level
> 原文:[https://docs.gitlab.com/ee/user/project/bulk_editing.html](https://docs.gitlab.com/ee/user/project/bulk_editing.html)
* [Bulk edit issues at the project level](#bulk-edit-issues-at-the-project-level)
* [Bulk edit merge requests at the project level](#bulk-edit-merge-requests-at-the-project-level)
# Bulk editing issues and merge requests at the project level[](#bulk-editing-issues-and-merge-requests-at-the-project-level "Permalink")
**注意:**批量编辑问题,史诗和合并请求在**组级别**也可用. 有关更多详细信息,请参阅[在组级别批量编辑问题,史诗和合并请求](../group/bulk_editing/index.html) .
如果要跨多个问题更新属性或合并请求,则可以通过批量编辑它们,即一起编辑它们来完成.
[![Bulk editing](img/5b2694c5d35f9fdb42b43bb1f38ec29c.png)](img/bulk-editing_v13_2.png)
## Bulk edit issues at the project level[](#bulk-edit-issues-at-the-project-level "Permalink")
**注意:**您需要具有[Reporter 或更高](../permissions.html)级别的权限才能管理问题.
When bulk editing issues in a project, you can edit the following attributes:
* 状态(打开/关闭)
* Assignee
* Epic(在[GitLab Premium](https://about.gitlab.com/pricing/) 13.2 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/210470)
* Milestone
* Labels
* 健康状况(在[GitLab Ultimate](https://about.gitlab.com/pricing/) 13.2 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/218395)
* Subscriptions
要同时更新多个项目问题:
1. 在一个项目中,转到 **问题>列表** .
2. 点击**编辑问题** . 屏幕右侧的侧边栏显示,其中包含可编辑的字段.
3. 选中要编辑的每个问题旁边的复选框.
4. 从边栏中选择适当的字段及其值.
5. Click **全部更新**.
## Bulk edit merge requests at the project level[](#bulk-edit-merge-requests-at-the-project-level "Permalink")
**注意:**您需要[开发人员或更高](../permissions.html)级别的权限才能管理合并请求.
在项目中批量编辑合并请求时,可以编辑以下属性:
* 状态(打开/关闭)
* Assignee
* Milestone
* Labels
* Subscriptions
要同时更新多个项目合并请求:
1. 在一个项目中,转到 **合并请求** .
2. 单击**编辑合并请求** . 屏幕右侧的侧边栏显示,其中包含可编辑的字段.
3. 选中要编辑的每个合并请求旁边的复选框.
4. 从边栏中选择适当的字段及其值.
5. Click **全部更新**.
\ No newline at end of file
# Code Owners
> 原文:[https://docs.gitlab.com/ee/user/project/code_owners.html](https://docs.gitlab.com/ee/user/project/code_owners.html)
* [Introduction](#introduction)
* [Why is this useful?](#why-is-this-useful)
* [How to set up Code Owners](#how-to-set-up-code-owners)
* [Approvals by Code Owners](#approvals-by-code-owners)
* [The syntax of Code Owners files](#the-syntax-of-code-owners-files)
# Code Owners[](#code-owners-starter "Permalink")
版本历史
*[GitLab Starter](https://about.gitlab.com/pricing/) 11.3 中[引入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/6916) .
* [支持](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/53182)在 GitLab Starter 12.1 中添加的[组名称空间](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/53182) .
*[GitLab Premium](https://about.gitlab.com/pricing/) 11.9 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/4418)了用于合并请求批准的代码所有者.
## Introduction[](#introduction "Permalink")
在为项目做贡献时,通常很难找出谁应该审查或批准合并请求. 此外,如果您对特定文件或代码块有疑问,可能很难知道从谁那里找到答案.
GitLab 代码所有者是一项功能,用于定义谁拥有存储库中的特定文件或路径,从而允许其他用户了解谁对每个文件或路径负责.
## Why is this useful?[](#why-is-this-useful "Permalink")
代码所有者允许使用版本控制的单个真实文件源,该文件概述了拥有存储库中某些文件或路径的确切 GitLab 用户或组. 可以在合并请求批准过程中利用代码所有者,该过程可以简化为给定合并请求找到合适的审阅者和批准者的过程.
在大型组织或流行的开源项目中,如果您遇到的问题可能与代码审查或合并请求批准无关,则代码所有者还可以帮助您了解与谁联系.
## How to set up Code Owners[](#how-to-set-up-code-owners "Permalink")
您可以使用`CODEOWNERS`文件来指定负责存储库中某些文件的用户或[共享组](members/share_project_with_groups.html) .
您可以在三个位置选择并添加`CODEOWNERS`文件:
* 到存储库的根目录
*`.gitlab/`目录中
*`docs/`目录中
The `CODEOWNERS` file is scoped to a branch, which means that with the introduction of new files, the person adding the new content can specify themselves as a code owner, all before the new changes get merged to the default branch.
当一个文件与`CODEOWNERS`文件中的多个条目匹配时,与该文件匹配的上一个模式的用户将显示在给定文件的 Blob 页面上. 例如,您具有以下`CODEOWNERS`文件:
```
README.md @user1
# This line would also match the file README.md
*.md @user2
```
将显示`README.md`的用户为`@user2` .
## Approvals by Code Owners[](#approvals-by-code-owners "Permalink")
将"代码所有者"设置为项目后,可以将其配置为用于合并请求批准:
* As [merge request eligible approvers](merge_requests/merge_request_approvals.html#code-owners-as-eligible-approvers).
* 根据需要批准[分支机构](protected_branches.html#protected-branches-approval-by-code-owners-premium) .
**注意** :为了批准合并请求,需要开发人员或更高[权限](../permissions.html) .
设置后,"代码所有者"将显示在合并请求小部件中:
[![MR widget - Code Owners](img/6deba2d9890a294d17564cce39fcbaef.png)](img/code_owners_mr_widget_v12_4.png)
尽管`CODEOWNERS`文件除了可以用于合并请求[批准规则之外](merge_requests/merge_request_approvals.html#approval-rules) ,还可以用作合并请求批准的唯一驱动程序(不使用[批准规则](merge_requests/merge_request_approvals.html#approval-rules) ). 为此,请在上面指定的三个位置之一中创建文件,并将代码所有者设置为[受保护分支的](protected_branches.html#protected-branches-approval-by-code-owners-premium)必需批准者. 使用[代码所有者文件的语法](code_owners.html#the-syntax-of-code-owners-files)来指定实际所有者和精细权限.
结合使用"代码所有者"和" [受保护的分支机构批准",](protected_branches.html#protected-branches-approval-by-code-owners-premium)将防止在`CODEOWNERS`文件中未指定的任何用户推送对指定文件/路径的更改,即使其角色包含在" **允许推送"**列中. 这允许采用更具包容性的推送策略,因为管理员不必限制开发人员直接将其推送到受保护的分支,而可以将推送限制到某些需要代码所有者审查的文件.
## The syntax of Code Owners files[](#the-syntax-of-code-owners-files "Permalink")
可以使用与`.gitignore`文件中使用的相同类型的模式来指定文件,然后使用一个或多个用户的`@username`或电子邮件或应作为文件所有者的一个或多个组的`@name`进行指定. 必须将组添加为[项目的成员](members/index.html) ,否则它们将被忽略.
[GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/32432)开始,您现在可以将项目组层次结构中的组或子组指定为潜在的代码所有者.
例如,考虑给定项目的以下层次结构:
```
group >> sub-group >> sub-subgroup >> myproject >> file.md
```
以下任何组都可以被指定为代码所有者:
* `@group`
* `@group/sub-group`
* `@group/sub-group/sub-subgroup`
此外,使用" **成员"**工具邀请到项目的任何组也将被视为合格的代码所有者.
定义路径的顺序很重要:与给定路径匹配的最后一个模式将用于查找代码所有者.
`#`开头的行表示注释. 需要使用`\#`对其进行转义,以寻址其名称以`#`开头的文件.
Example `CODEOWNERS` file:
```
# This is an example of a code owners file
# lines starting with a `#` will be ignored.
# app/ @commented-rule
# We can specify a default match using wildcards:
* @default-codeowner
# We can also specify "multiple tab or space" separated codeowners:
* @multiple @code @owners
# Rules defined later in the file take precedence over the rules
# defined before.
# This will match all files for which the file name ends in `.rb`
*.rb @ruby-owner
# Files with a `#` can still be accessed by escaping the pound sign
\#file_with_pound.rb @owner-file-with-pound
# Multiple codeowners can be specified, separated by spaces or tabs
# In the following case the CODEOWNERS file from the root of the repo
# has 3 code owners (@multiple @code @owners)
CODEOWNERS @multiple @code @owners
# Both usernames or email addresses can be used to match
# users. Everything else will be ignored. For example this will
# specify `@legal` and a user with email `janedoe@gitlab.com` as the
# owner for the LICENSE file
LICENSE @legal this_does_not_match janedoe@gitlab.com
# Group names can be used to match groups and nested groups to specify
# them as owners for a file
README @group @group/with-nested/subgroup
# Ending a path in a `/` will specify the code owners for every file
# nested in that directory, on any level
/docs/ @all-docs
# Ending a path in `/*` will specify code owners for every file in
# that directory, but not nested deeper. This will match
# `docs/index.md` but not `docs/projects/index.md`
/docs/* @root-docs
# This will make a `lib` directory nested anywhere in the repository
# match
lib/ @lib-owner
# This will only match a `config` directory in the root of the
# repository
/config/ @config-owner
# If the path contains spaces, these need to be escaped like this:
path\ with\ spaces/ @space-owner
```
\ No newline at end of file
# Compliance
> 原文:[https://docs.gitlab.com/ee/user/compliance/](https://docs.gitlab.com/ee/user/compliance/)
# Compliance[](#compliance-ultimate "Permalink")
GitLab 提供的合规性工具可让您随时关注项目的各个方面. 可以使用以下合规工具:
* [Compliance Dashboard](compliance_dashboard/index.html) :查看组中所有项目的最近合并请求活动. 这使您可以查看合并请求是否被批准以及由谁批准.
* [许可证合规性](license_compliance/index.html) :在项目的依存关系中搜索其许可证. 这样,您可以确定项目依赖项的许可证是否与项目的许可证兼容.
\ No newline at end of file
此差异已折叠。
# Compliance Dashboard
> 原文:[https://docs.gitlab.com/ee/user/compliance/compliance_dashboard/](https://docs.gitlab.com/ee/user/compliance/compliance_dashboard/)
* [Overview](#overview)
* [Use cases](#use-cases)
* [Permissions](#permissions)
# Compliance Dashboard[](#compliance-dashboard-ultimate "Permalink")
[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/36524) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.8.
Compliance Dashboard 通过为组中的所有项目提供高级视图,使您能够查看组的"合并请求"活动. 例如,批准用于合并的代码.
## Overview[](#overview "Permalink")
要访问组的合规性仪表板,请导航至 组菜单上的" **安全性和合规性">"合规性** ".
[![Compliance Dashboard](img/da827bb1926cf748cff537fec6ecc954.png)](img/compliance_dashboard_v13_2.png)
## Use cases[](#use-cases "Permalink")
此功能适用于关心团队中项目的合规性状态的人员.
您可以使用仪表板执行以下操作:
* 概述每个项目的最新合并请求.
* 查看合并请求是否被批准以及由谁批准.
* 请参阅合并请求作者.
* 查看每个合并请求的最新[CI 管道](../../../ci/pipelines/index.html)结果.
## Permissions[](#permissions "Permalink")
* On [GitLab Ultimate](https://about.gitlab.com/pricing/) tier.
* By **Administrators** and **集团所有者**.
\ No newline at end of file
# Create a project
> 原文:[https://docs.gitlab.com/ee/gitlab-basics/create-project.html](https://docs.gitlab.com/ee/gitlab-basics/create-project.html)
* [Create a project in GitLab](#create-a-project-in-gitlab)
* [Blank projects](#blank-projects)
* [Project templates](#project-templates)
* [Built-in templates](#built-in-templates)
* [Enterprise templates](#enterprise-templates-ultimate)
* [Custom project templates](#custom-project-templates-premium)
* [Push to create a new project](#push-to-create-a-new-project)
# Create a project[](#create-a-project "Permalink")
GitLab 中的大多数工作都在一个[Project 中](../user/project/index.html)完成. 文件和代码保存在项目中,并且大多数功能都在项目范围内使用.
## Create a project in GitLab[](#create-a-project-in-gitlab "Permalink")
要在 GitLab 中创建项目:
1. 在信息中心中,点击绿色的**新建项目**按钮或使用导航栏中的加号图标. 这将打开" **新项目"**页面.
2. 在" **新建项目"**页面上,选择是否要:
* 创建一个[空白项目](#blank-projects) .
* 使用可用的[项目模板](#project-templates)之一创建一个项目.
* 如果已在您的 GitLab 实例上启用,则从其他存储库[导入项目](../user/project/import/index.html) . 如果不可用,请与您的 GitLab 管理员联系.
* 运行[用于外部存储库的 CI / CD 管道](../ci/ci_cd_for_external_repos/index.html) .
**注意:**有关不能用作项目名称的单词列表,请参见[保留的项目和组名称](../user/reserved_names.html) .
### Blank projects[](#blank-projects "Permalink")
要在" **新建项目"**页面上创建一个新的空白项目,请执行以下操作:
1. 在" **空白项目"**选项卡上,提供以下信息:
* **项目名称****项目名称**字段中. 您不能使用特殊字符,但可以使用空格,连字符,下划线甚至表情符号. 添加名称时, **Project slug**将自动填充. slug 是 GitLab 实例将用作项目的 URL 路径的东西. 如果您要使用其他子弹,请先输入项目名称,然后再更改子弹.
* **Project slug**字段中项目的路径. 这是 GitLab 实例将使用的项目的 URL 路径. 如果**项目名称**为空白,则当您填写**项目 slug**时,它将自动填充.
* 使用" **项目描述"(可选)**字段,您可以为项目的仪表板输入描述,这将帮助其他人了解您的项目的含义. 尽管不是必需的,但这是个好主意.
* 更改" **可见性级别"**会修改用户的项目[查看和访问权限](../public_access/public_access.html) .
* 选择**使用 README 初始化存储库**选项将创建一个 README 文件,以便 Git 存储库被初始化,具有默认分支并可以被克隆.
2. Click **建立专案**.
### Project templates[](#project-templates "Permalink")
项目模板可以使用必要的文件预填充新项目,以使您快速入门.
有两种类型的项目模板:
* [内置模板](#built-in-templates) ,来自以下组:
* [`project-templates`](https://gitlab.com/gitlab-org/project-templates)
* [`pages`](https://gitlab.com/pages)
* [自定义项目模板](#custom-project-templates-premium) ,用于由 GitLab 管理员和用户配置的自定义模板.
#### Built-in templates[](#built-in-templates "Permalink")
内置模板是项目模板,它们是:
*[`project-templates`](https://gitlab.com/gitlab-org/project-templates)[`pages`](https://gitlab.com/pages)组中开发和维护.
* 与 GitLab 一起发布.
要在" **新建项目"**页面上使用内置模板,请执行以下操作:
1. 在" **从模板创建"**选项卡上,选择" **内置"**选项卡.
2. 从可用的内置模板列表中,单击:
* **预览**按钮以查看模板源本身.
* **使用模板**按钮开始创建项目.
3. 通过填写项目的详细信息来完成创建项目. 该过程与创建[空白项目](#blank-projects)相同.
##### Enterprise templates[](#enterprise-templates-ultimate "Permalink")
GitLab 正在开发企业模板,以帮助您根据选定的法规标准简化审核管理. 这些模板会自动导入与每个法规要求相对应的问题.
要使用企业模板创建新项目,请在" **新建项目"**页面上:
1. 在" **从模板创建"**选项卡上,选择" **内置"**选项卡.
2. 从可用的内置企业模板列表中,单击:
* **预览**按钮以查看模板源本身.
* **使用模板**按钮开始创建项目.
3. 通过填写项目的详细信息来完成创建项目. 该过程与创建[空白项目](#blank-projects)相同.
可用的企业模板包括:
* HIPAA 审核协议模板(在 GitLab 12.10 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/13756)
**提示:**您可以按照[以下步骤](https://gitlab.com/gitlab-org/project-templates/contributing)改进现有的内置模板或在[`project-templates`](https://gitlab.com/gitlab-org/project-templates)[`pages`](https://gitlab.com/pages)组中添加新的[`project-templates`](https://gitlab.com/gitlab-org/project-templates) .
#### Custom project templates[](#custom-project-templates-premium "Permalink")
[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/6860) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.2.
Creating new projects based on custom project templates is a convenient option for quickly starting projects.
自定义项目可以在[实例级别](../user/admin_area/custom_project_templates.html)**实例**选项卡,或在[组级别](../user/group/custom_project_templates.html)**组**选项卡,在**从模板**标签上的**创建** .
要在" **新建项目"**页面上使用自定义项目模板:
1. 在" **从模板创建"**选项卡上,选择" **实例"**选项卡或" **组"**选项卡.
2. 从可用的自定义模板列表中,单击:
* **预览**按钮以查看模板源本身.
* **使用模板**按钮开始创建项目.
3. 通过填写项目的详细信息来完成创建项目. 该过程与创建[空白项目](#blank-projects)相同.
## Push to create a new project[](#push-to-create-a-new-project "Permalink")
在 GitLab 10.5 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/26388) .
当您在本地创建新的存储库时,无需直接在 GitLab 上手动创建一个新项目然后[](start-using-git.html#clone-a-repository)本地[克隆该](start-using-git.html#clone-a-repository)存储库,而无需将其直接发送到 GitLab 即可创建新项目. 如果您具有关联的名称空间的访问权,则 GitLab 将在该 GitLab 名称空间下自动创建一个新项目,其可见性默认设置为 Private(您以后可以在[项目的设置中](../public_access/public_access.html#how-to-change-project-visibility)对其进行更改).
这可以通过使用 SSH 或 HTTPS 来完成:
```
## Git push using SSH
git push --set-upstream git@gitlab.example.com:namespace/nonexistent-project.git master
## Git push using HTTPS
git push --set-upstream https://gitlab.example.com/namespace/nonexistent-project.git master
```
推送成功完成后,将显示一条远程消息,指示将遥控器和 URL 设置为新项目的命令:
```
remote:
remote: The private project namespace/nonexistent-project was created.
remote:
remote: To configure the remote, run:
remote: git remote add origin https://gitlab.example.com/namespace/nonexistent-project.git
remote:
remote: To view the project, visit:
remote: https://gitlab.example.com/namespace/nonexistent-project
remote:
```
\ No newline at end of file
# Description templates
> 原文:[https://docs.gitlab.com/ee/user/project/description_templates.html](https://docs.gitlab.com/ee/user/project/description_templates.html)
* [Overview](#overview)
* [Use-cases](#use-cases)
* [Creating issue templates](#creating-issue-templates)
* [Creating merge request templates](#creating-merge-request-templates)
* [Using the templates](#using-the-templates)
* [Setting a default template for merge requests and issues](#setting-a-default-template-for-merge-requests-and-issues-starter)
* [Description template example](#description-template-example)
# Description templates[](#description-templates "Permalink")
在 GitLab 8.11 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/4981) .
我们都知道,项目开发人员更有可能及时解决提交的问题.
使用描述模板,您可以为问题定义特定于上下文的模板,并为项目合并请求描述字段,并帮助从问题中过滤掉许多不必要的噪音.
## Overview[](#overview "Permalink")
通过使用描述模板,创建新发行或合并请求的用户可以选择描述模板,以帮助他们与其他贡献者进行有效沟通.
每个 GitLab 项目都可以定义自己的一组描述模板,这些模板将被添加到 GitLab 项目存储库的根目录中.
描述模板必须用[Markdown](../markdown.html)编写,并存储在项目的存储库中的`.gitlab`目录下. 仅考虑默认分支的模板.
## Use-cases[](#use-cases "Permalink")
* 添加一个模板,该模板将用于特定项目的每个问题,并提供说明和指南,要求提供特定于该主题的信息. 例如,如果您有一个用于跟踪新博客文章的项目,则可以要求标题,大纲,作者姓名,作者社交媒体信息等等.
* 在前面的示例之后,您可以为随新博客帖子提交的每个 MR 创建模板,要求提供有关帖子日期,前事数据,图像准则,相关问题的链接,审阅者姓名等信息.
* 您还可以为工作流的不同阶段创建问题并合并请求模板,例如功能建议,功能改进或错误报告.
## Creating issue templates[](#creating-issue-templates "Permalink")
在存储库的`.gitlab/issue_templates/`目录内创建一个新的 Markdown( `.md` )文件. 提交并推送到您的默认分支.
To create a Markdown file:
1. 单击`master`旁边的`+`按钮,然后单击**New file** .
2. 将问题模板的名称添加到`master`旁边的**File name**文本字段中. 确保单词之间用下划线分隔,并且文件的扩展名为`.md` ,例如`feature_request.md` .
3. 提交并推送到您的默认分支.
如果您的存储库中没有`.gitlab/issue_templates`目录,则需要创建它.
要创建`.gitlab/issue_templates`目录:
1. 单击`master`旁边的`+`按钮,然后选择**New directory** .
2. 将此新目录`.gitlab`并提交到默认分支.
3. 再次单击`master`旁边的`+`按钮,然后选择**New directory** .这次,n
4. 将目录`issue_templates`并提交到默认分支.
要检查它是否正常工作,请[创建一个新问题,](./issues/managing_issues.html#create-a-new-issue)然后查看是否可以选择描述模板.
## Creating merge request templates[](#creating-merge-request-templates "Permalink")
与发布模板类似,在存储库的`.gitlab/merge_request_templates/`目录内创建一个新的 Markdown( `.md` )文件. 提交并推送到您的默认分支.
## Using the templates[](#using-the-templates "Permalink")
让我们以创建了`.gitlab/issue_templates/Bug.md`文件`.gitlab/issue_templates/Bug.md` . 在创建或编辑问题时,这将启用`Bug`下拉选项. 选择`Bug``Bug.md`模板文件中的内容将被复制到问题描述字段. "重置模板"按钮将放弃您在选择模板后所做的任何更改,并将其恢复为初始状态.
[![Description templates](img/6224c1a367d53cc7bb5c5536af96ec6e.png)](img/description_templates.png)
## Setting a default template for merge requests and issues[](#setting-a-default-template-for-merge-requests-and-issues-starter "Permalink")
版本历史
* 此功能是在[描述模板](#overview)之前引入的,可在[GitLab Starter 中使用](https://about.gitlab.com/pricing/) . 可以在项目设置中启用它.
* 问题模板在 GitLab EE 8.1 中[引入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28) .
* 在 GitLab EE 6.9 中[引入](https://gitlab.com/gitlab-org/gitlab/commit/7478ece8b48e80782b5465b96c79f85cc91d391b)了合并请求的模板.
在项目的**"设置" /"可见性","项目功能","权限"**部分中,应将问题和/或合并请求的可见性设置为"每个人都可以访问"或"只有项目成员",否则模板文本区域将不会显示. 这是默认行为,因此在大多数情况下都可以.
1. 转到项目的**"设置"** .
2. 单击**合并请求**标题下的**展开** .
3. 填写" **合并请求****默认描述模板"**文本区域.
4. Click **Expand** under **默认问题模板**.
5. 填写问题的**默认描述模板**文本区域. 由于 GitLab 合并请求和问题支持[Markdown](../markdown.html) ,因此您可以使用它来格式化标题,列表等.
[![Default merge request description templates](img/c7ee3e55c50a5f7d0e3faceda16e2dc2.png)](img/description_templates_merge_request_settings.png)
[![Default issue description templates](img/c9d2a45b5906d81d1118b63a832bbcd4.png)](img/description_templates_issue_settings.png)
添加描述后,点击**保存更改**以使设置生效. 现在,每次创建新的合并请求或问题时,都将使用您在模板中输入的文本预先填充.
## Description template example[](#description-template-example "Permalink")
我们在 GitLab 社区版项目中使用问题和合并请求的描述模板. 请参考[`.gitlab`文件夹](https://gitlab.com/gitlab-org/gitlab/tree/master/.gitlab)中的一些示例.
**提示:**可以在描述模板中使用[快速操作](quick_actions.html)来快速添加标签,受让人和里程碑. 仅当提交问题或合并请求的用户有权执行相关操作时,才执行快速操作.
这是错误报告模板的示例:
```
Summary
(Summarize the bug encountered concisely)
Steps to reproduce
(How one can reproduce the issue - this is very important)
Example Project
(If possible, please create an example project here on GitLab.com that exhibits the problematic behaviour, and link to it here in the bug report)
(If you are using an older version of GitLab, this will also determine whether the bug has been fixed in a more recent version)
What is the current bug behavior?
(What actually happens)
What is the expected correct behavior?
(What you should see instead)
Relevant logs and/or screenshots
(Paste any relevant logs - please use code blocks (```) to format console output,
logs, and code as it's very hard to read otherwise.)
Possible fixes
(If you can, link to the line of code that might be responsible for the problem)
/label ~bug ~reproduced ~needs-investigation
/cc @project-manager
/assign @qa-tester
```
\ No newline at end of file
# Deploy Keys
> 原文:[https://docs.gitlab.com/ee/user/project/deploy_keys/](https://docs.gitlab.com/ee/user/project/deploy_keys/)
* [Key details on deploy keys](#key-details-on-deploy-keys)
* [Deploy Keys Permissions](#deploy-keys-permissions)
* [Differences between deploy keys and deploy tokens](#differences-between-deploy-keys-and-deploy-tokens)
* [How to enable Deploy Keys](#how-to-enable-deploy-keys)
* [Project deploy keys](#project-deploy-keys)
* [Public deploy keys](#public-deploy-keys)
* [Troubleshooting](#troubleshooting)
* [Deploy Key cannot push to a protected branch](#deploy-key-cannot-push-to-a-protected-branch)
# Deploy Keys[](#deploy-keys "Permalink")
通过将 SSH 公钥导入到 GitLab 实例,部署密钥允许对一个或多个存储库的只读或读写(如果启用)访问.
这对于将存储库克隆到持续集成(CI)服务器非常有用. 通过使用部署密钥,您不必设置虚拟用户帐户.
There are two types of deploy keys:
* [Project deploy keys](#project-deploy-keys)
* [Public deploy keys](#public-deploy-keys)
## Key details on deploy keys[](#key-details-on-deploy-keys "Permalink")
部署密钥使远程机器(VM,物理机等)只需几个步骤即可访问 GitLab 存储库. 如果您希望远程计算机以自动化方式与 GitLab 存储库进行交互,这是一个简单的解决方案.
缺点是,如果远程计算机被黑客入侵,则您的存储库可能会变得脆弱. 在存储库中启用部署密钥之前,应限制对远程计算机的访问. 遵循的好规则是仅访问受信任的用户,并确保允许的用户在 GitLab 项目中具有[维护者权限或更高权限](../../permissions.html) .
如果您的组织担心这种安全隐患,则可以使用" [部署令牌"](../deploy_tokens/index.html)作为替代方案,但具有更多的安全控制.
## Deploy Keys Permissions[](#deploy-keys-permissions "Permalink")
在项目上启用部署密钥时,可以选择其访问级别:
* `read-only` :部署密钥可以读取存储库.
* `read-write` :部署密钥可以读取存储库并对其进行写入.
项目维护者和所有者可以激活和停用部署密钥. 他们还可以添加自己的部署密钥并为该项目启用它们.
当使用`write-access`部署密钥来推送提交时,GitLab 会检查部署密钥的**创建者**是否有权访问资源. 例如:
* 当使用部署密钥将提交推送到[受保护的分支时](../protected_branches.html) ,部署密钥的**创建者**必须有权访问该分支.
* 当使用部署密钥来推送触发 CI / CD 管道的提交时,部署密钥的**创建者**必须有权访问 CI / CD 资源(例如受保护的环境,机密变量等).
* 如果部署密钥的**创建者**没有读取项目存储库的权限,则部署密钥*可能*在此过程中遇到错误.
## Differences between deploy keys and deploy tokens[](#differences-between-deploy-keys-and-deploy-tokens "Permalink")
部署密钥和[部署令牌](../deploy_tokens/index.html#deploy-tokens)都可以帮助您访问存储库,但是它们之间存在一些显着差异:
* 部署密钥可以在不相关甚至不属于同一组的项目之间共享. 部署令牌属于项目或[](../deploy_tokens/index.html#group-deploy-token) .
* 部署密钥是您需要在计算机上生成自己的 SSH 密钥. 部署令牌是由您的 GitLab 实例生成的,仅在创建时提供给用户一次.
* 只要已注册并启用部署密钥,该密钥便有效. 部署令牌可能是时间敏感的,因为您可以通过设置令牌的到期日期来控制令牌的有效性.
* 您不能使用部署密钥登录注册表,也不能对其执行读/写操作,但是[使用部署令牌是可以的](../deploy_tokens/index.html#gitlab-deploy-token) .
* 您需要 SSH 密钥对才能使用部署密钥,但不需要部署令牌.
## How to enable Deploy Keys[](#how-to-enable-deploy-keys "Permalink")
### Project deploy keys[](#project-deploy-keys "Permalink")
[项目维护者和所有者](../../permissions.html#project-members-permissions)可以为项目存储库添加或启用部署密钥:
1. 导航到项目的**"设置">"存储库"**页面.
2. 展开" **部署密钥"**部分.
3. 为新的部署密钥指定标题,然后粘贴您的公共 SSH 密钥.
4. (可选)检查**写访问允许**允许`read-write`访问. 保留它的`read-only`访问权限.
有三个项目部署密钥列表:
* 启用的部署密钥
* Privately accessible deploy keys
* 公共可访问的部署密钥
[![Deploy Keys section](img/86738432aa05c0c68fffb68c00788fa4.png)](img/deploy_keys_v13_0.png)
添加密钥后,默认情况下将为此项目启用该密钥,它将显示在"已**启用的部署密钥"**选项卡中.
在"私有**可访问的部署密钥"**选项卡中,您可以启用已导入到其他项目中的私有密钥. 如果您有权访问这些密钥,那是因为您具有以下任一能力:
* 以前,您自己将密钥上传到了另一个项目中.
* 您是导入密钥的另一个项目的维护者或所有者.
在可**公开访问的部署密钥**选项卡中,您可以启用[对整个 GitLab 实例可用的](#public-deploy-keys)密钥.
添加密钥后,您可以对其进行编辑以更新其标题,或者在`read-only``read-write`访问之间切换.
**注意:**如果您为项目启用了私有或公共访问或部署密钥,并且随后将该密钥的访问级别从`read-only`更新为`read-write` ,则更改将仅适用于**当前项目** .
### Public deploy keys[](#public-deploy-keys "Permalink")
公共部署密钥允许对 GitLab 实例中的任何存储库进行`read-only``read-write`访问. 这对于将存储库集成到安全的共享服务(例如 CI / CD)很有用.
实例管理员可以添加公共部署密钥:
1. 转到**管理区域** ( ) **>部署密钥** .
2. 单击**新部署密钥** .
确保新密钥具有有意义的标题,因为这是项目维护者和所有者识别要添加的正确公共部署密钥的主要方法. 例如,如果密钥允许访问 SaaS CI / CD 实例,请在密钥名称中使用该服务的名称(如果已使用了所有密钥).
[![Public Deploy Keys section](img/2d13f3059b88ccaf448646ed61f70d47.png)](img/public_deploy_key_v13_0.png)
添加密钥后,它将对所有共享系统可用. 项目维护者或更高级别的人员可以[授权公共部署密钥](#project-deploy-keys)开始在项目中使用它.
**注意:**仅在配置了至少一个公共部署密钥的情况下,Project CI / CD 设置中的" **公共可访问部署密钥"**选项卡才会显示.
与项目部署密钥相比,公共部署密钥可以提供更高的安全性,因为目标集成系统的管理员是唯一需要知道或配置密钥值的管理员.
创建公共部署密钥时,请确定是否可以针对非常狭窄的用途(例如仅特定服务)定义它,或者是否需要针对更广泛的用途(例如对所有服务进行完全`read-write`访问)进行定义.
**警告:**添加公共部署密钥不会立即向其公开任何存储库. 公共部署密钥允许从其他系统进行访问,但是只有项目维护者选择使用它之后,才能访问任何项目.
## Troubleshooting[](#troubleshooting "Permalink")
### Deploy Key cannot push to a protected branch[](#deploy-key-cannot-push-to-a-protected-branch "Permalink")
如果此部署密钥的所有者无权访问[受保护的分支](../protected_branches.html) ,则此部署密钥也将无权访问该分支. 除此之外,在["允许推送"部分中](../protected_branches.html#configuring-protected-branches)选择" **否"**值意味着没有用户**和**使用部署密钥的服务都无法推送到该选定分支.
有关更多信息,请参考[此问题](https://gitlab.com/gitlab-org/gitlab/-/issues/30769) .
\ No newline at end of file
# Deploy Tokens
> 原文:[https://docs.gitlab.com/ee/user/project/deploy_tokens/](https://docs.gitlab.com/ee/user/project/deploy_tokens/)
* [Creating a Deploy Token](#creating-a-deploy-token)
* [Deploy token expiration](#deploy-token-expiration)
* [Revoking a deploy token](#revoking-a-deploy-token)
* [Limiting scopes of a deploy token](#limiting-scopes-of-a-deploy-token)
* [Deploy token custom username](#deploy-token-custom-username)
* [Usage](#usage)
* [Git clone a repository](#git-clone-a-repository)
* [Read Container Registry images](#read-container-registry-images)
* [Push Container Registry images](#push-container-registry-images)
* [Read or pull packages](#read-or-pull-packages)
* [Push or upload packages](#push-or-upload-packages)
* [Group Deploy Token](#group-deploy-token)
* [GitLab Deploy Token](#gitlab-deploy-token)
# Deploy Tokens[](#deploy-tokens "Permalink")
版本历史
* 在 GitLab 10.7 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17894) .
* 从 GitLab 12.9 中的**设置>存储库** [移动](https://gitlab.com/gitlab-org/gitlab/-/issues/199370) .
* 在 GitLab 12.10 中[添加了`write_registry`范围](https://gitlab.com/gitlab-org/gitlab/-/issues/22743) .
* 从 GitLab 12.10.1.中的**"设置">" CI / CD"** [移动](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/29280) .
* 在 GitLab 13.0 中[添加了软件包注册表范围](https://gitlab.com/gitlab-org/gitlab/-/issues/213566) .
部署令牌使您无需用户和密码即可下载( `git clone` )或推和拉项目的程序包和容器注册表映像.
部署令牌只能由[维护者](../../permissions.html)管理.
如果有密钥对,则可能要改用[部署密钥](../../../ssh/README.html#deploy-keys) .
## Creating a Deploy Token[](#creating-a-deploy-token "Permalink")
您可以从项目的设置中创建任意数量的部署令牌. 或者,您也可以创建[组范围的部署令牌](#group-deploy-token) .
1. 登录到您的 GitLab 帐户.
2. 转到要为其创建"部署令牌"的项目(或组).
3.**设置** > **存储库** .
4. 单击" **部署令牌"**部分上的"扩展".
5. 选择令牌的名称,有效期(可选)和用户名(可选).
6. 选择[所需的范围](#limiting-scopes-of-a-deploy-token) .
7. 单击**创建部署令牌** .
8. 将部署令牌保存在安全的地方. 离开或刷新页面后, **您将无法再次访问它** .
[![Personal access tokens page](img/90bcd1f29936328bfb5d344868b8bb81.png)](img/deploy_tokens.png)
## Deploy token expiration[](#deploy-token-expiration "Permalink")
部署令牌在您定义的日期 UTC 午夜到期.
## Revoking a deploy token[](#revoking-a-deploy-token "Permalink")
您可以随时单击"活动的部署令牌"区域下的相应" **撤消"**按钮来撤消任何部署令牌.
## Limiting scopes of a deploy token[](#limiting-scopes-of-a-deploy-token "Permalink")
可以使用不同的作用域创建部署令牌,这些作用域允许给定令牌可以执行各种操作. 下表介绍了可用的范围以及引入的 GitLab 版本.
| Scope | Description | 在 GitLab 版本中引入 |
| --- | --- | --- |
| `read_repository` | 允许通过`git clone`对存储库进行读取访问 | 10.7 |
| `read_registry` | 如果项目是私有的并且需要授权,则允许对[容器注册表](../../packages/container_registry/index.html)图像的读取访问. | 10.7 |
| `write_registry` | Allows write-access (push) to [container registry](../../packages/container_registry/index.html). | 12.10 |
| `read_package_registry` | 允许对包注册表进行读取访问. | 13.0 |
| `write_package_registry` | 允许对程序包注册表的写访问. | 13.0 |
## Deploy token custom username[](#deploy-token-custom-username "Permalink")
在 GitLab 12.1 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/29639) .
默认的用户名格式为`gitlab+deploy-token-#{n}` . 某些工具或平台可能不支持此格式,在这种情况下,您可以指定在创建部署令牌时要使用的自定义用户名.
## Usage[](#usage "Permalink")
### Git clone a repository[](#git-clone-a-repository "Permalink")
要使用部署令牌下载存储库,您只需要:
1. 创建一个以`read_repository`为范围的部署令牌.
2. 记下您的`username``token` .
3. `git clone`使用 Deploy Token `git clone`项目:
```
git clone https://<username>:<deploy_token>@gitlab.example.com/tanuki/awesome_project.git
```
`<username>``<deploy_token>`替换为正确的值.
### Read Container Registry images[](#read-container-registry-images "Permalink")
要读取容器注册表图像,您需要:
1. 使用`read_registry`作为范围创建部署令牌.
2. 记下您的`username``token` .
3. 使用部署令牌登录到 GitLab 的 Container Registry:
```
docker login -u <username> -p <deploy_token> registry.example.com
```
只需将`<username>``<deploy_token>`替换为适当的值即可. 然后,您可以简单地从 Container Registry 中提取图像.
### Push Container Registry images[](#push-container-registry-images "Permalink")
在 GitLab 12.10 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/22743) .
要推送容器注册表映像,您需要:
1. 创建一个具有`write_registry`作为范围的部署令牌.
2. 记下您的`username``token` .
3. 使用部署令牌登录到 GitLab 的 Container Registry:
```
docker login -u <username> -p <deploy_token> registry.example.com
```
只需将`<username>``<deploy_token>`替换为适当的值即可. 然后,您可以简单地将图像推送到 Container Registry.
### Read or pull packages[](#read-or-pull-packages "Permalink")
在 GitLab 13.0 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/213566) .
要在 GitLab 软件包注册表中提取软件包,您需要:
1. 使用`read_package_registry`作为范围创建一个部署令牌.
2. 记下您的`username``token` .
3. 对于[您选择](./../../packages/index.html)[软件包类型,请](./../../packages/index.html)遵循有关部署令牌的身份验证说明.
### Push or upload packages[](#push-or-upload-packages "Permalink")
在 GitLab 13.0 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/213566) .
要在 GitLab 软件包注册表中上传软件包,您需要:
1. 使用`write_package_registry`作为范围创建部署令牌.
2. 记下您的`username``token` .
3. 对于[您选择](./../../packages/index.html)[软件包类型,请](./../../packages/index.html)遵循有关部署令牌的身份验证说明.
### Group Deploy Token[](#group-deploy-token "Permalink")
在 GitLab 12.9 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/21765) .
在组级别创建的部署令牌可在属于特定组或其子组之一的所有项目中使用.
有关概述,请参阅" [组部署令牌"](https://youtu.be/8kxTJvaD9ks) .
要使用组部署令牌:
1. 为组[创建](#creating-a-deploy-token)一个部署令牌.
2.[克隆存储库](#git-clone-a-repository)时使用项目部署令牌的方式相同.
克隆相关项目的存储库时,应用于组部署令牌的范围(例如`read_repository` )将一致地应用.
### GitLab Deploy Token[](#gitlab-deploy-token "Permalink")
在 GitLab 10.8 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/18414) .
部署令牌是一种特殊情况. 如果用户创建了一个名为`gitlab-deploy-token`的名称,则 Deploy Token 的用户名和令牌将自动作为环境变量暴露给 CI / CD 作业: `CI_DEPLOY_USER``CI_DEPLOY_PASSWORD` .
创建令牌后,可以使用以下变量登录到 Container Registry:
```
docker login -u $CI_DEPLOY_USER -p $CI_DEPLOY_PASSWORD $CI_REGISTRY
```
**注意:**目前尚未为组部署令牌实现`gitlab-deploy-token`部署令牌的特殊处理. 为了使部署令牌可用于 CI / CD 作业,必须在项目级别创建它. 有关详细信息,请参[见此问题](https://gitlab.com/gitlab-org/gitlab/-/issues/214014) .
\ No newline at end of file
此差异已折叠。
# Project integrations
> 原文:[https://docs.gitlab.com/ee/user/project/integrations/](https://docs.gitlab.com/ee/user/project/integrations/)
* [Integrations](#integrations)
* [Project webhooks](#project-webhooks)
# Project integrations[](#project-integrations "Permalink")
您可以在项目的**设置➔集成**页面下找到可用的集成. 您至少需要对该项目具有[维护者权限](../../permissions.html) .
## Integrations[](#integrations "Permalink")
集成使您可以将 GitLab 与其他应用程序集成. 它们有点像插件,因为它们为 GitLab 添加功能提供了很大的自由度.
[Learn more about integrations.](overview.html)
## Project webhooks[](#project-webhooks "Permalink")
通过项目 webhooks,您可以在例如推送新代码或创建新问题时触发 URL. 您可以将 webhook 配置为侦听特定事件,例如推送,问题或合并请求. GitLab 会将带有数据的 POST 请求发送到 webhook URL.
[Learn more about webhooks.](webhooks.html)
\ No newline at end of file
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
> 原文:[https://docs.gitlab.com/ee/user/project/merge_requests/authorization_for_merge_requests.html](https://docs.gitlab.com/ee/user/project/merge_requests/authorization_for_merge_requests.html)
\ No newline at end of file
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册