开发风格指南
编辑器/IDE 样式标准化
我们使用 EditorConfig 在文件本地保存前自动应用某些样式标准。一些编辑器和 IDE 默认会自动支持 .editorconfig 设置。
如果您的编辑器或 IDE 不自动支持 .editorconfig，我们建议调查 是否存在插件。例如，vim 的插件。
Pre-commit 和 pre-push 静态分析使用 Lefthook
Lefthook 是一个 Git hooks 管理器，允许在 Git 提交或推送之前执行自定义逻辑。GitLab 自带 Lefthook 配置（lefthook.yml），但必须安装。
我们有一个已提交的 lefthook.yml，但在安装 Lefthook 之前会被忽略。
卸载 Overcommit
我们在使用 Lefthook 之前使用的是 Overcommit，所以您可能需要先用 overcommit --uninstall 卸载它。
安装 Lefthook
-
您可以通过 不同方式 安装 lefthook。如果您选择不全局安装（例如通过 Homebrew 或包管理器），而只想在 GitLab 项目中使用，可以通过以下方式安装 Ruby gem：
bundle install -
安装 Lefthook 管理的 Git hooks：
# 如果全局安装 lefthook install # 或者如果通过 ruby gem 安装 bundle exec lefthook install -
通过运行 Lefthook
pre-pushGit hook 测试 Lefthook 是否正常工作：# 如果全局安装 lefthook run pre-push # 或者如果通过 ruby gem 安装 bundle exec lefthook run pre-push
这应该返回 Lefthook 版本和可执行命令列表及其输出。
Lefthook 配置
Lefthook 通过以下组合进行配置：
lefthook.yml中的项目配置。- 任何 本地配置。
Lefthook 自动修复文件
我们有一个自定义的 lefthook 目标来运行所有具有自动修复功能的 linter，但仅针对您分支中更改的文件。
# 如果全局安装
lefthook run auto-fix
# 或者如果通过 ruby gem 安装
bundle exec lefthook run auto-fix临时禁用 Lefthook
要临时禁用 Lefthook，您可以将 LEFTHOOK 环境变量设置为 0。例如：
LEFTHOOK=0 git push ...手动运行 Lefthook hooks
您可以手动运行 pre-commit、pre-push 和 auto-fix hooks。例如：
bundle exec lefthook run pre-push有关更多信息，请查看 Lefthook 文档。
基于 tag 跳过 Lefthook 检查
要在推送时基于标签跳过某些检查，您可以设置 LEFTHOOK_EXCLUDE 环境变量。例如：
LEFTHOOK_EXCLUDE=frontend,documentation git push ...或者，您可以创建具有以下结构的 lefthook-local.yml：
pre-push:
exclude_tags:
- frontend
- documentation有关更多信息，请查看 Lefthook 文档。
跳过或启用特定的 Lefthook 检查
要在推送时基于名称跳过或启用某个检查，您可以在该 hook 的 lefthook-local.yml 部分添加 skip: true 或 skip: false。例如，您可能希望启用 gettext 检查来检测 locale/gitlab.pot 的问题：
pre-push:
commands:
gettext:
skip: false有关更多信息，请查看 Lefthook 文档 Skipping commands section。
数据库迁移
请参阅专门的 数据库迁移风格指南。
JavaScript
请参阅专门的 JS 风格指南。
SCSS
请参阅专门的 SCSS 风格指南。
Ruby
请参阅专门的 Ruby 风格指南。
Go
请参阅专门的 Go 标准和风格指南。
Shell 命令 (Ruby)
请参阅专门的 GitLab 代码库中 shell 命令的指南。
Shell 脚本
请参阅专门的 Shell 脚本标准和风格指南。
发布 NPM 包到 npmjs.com
请参阅专门的 npmjs 包发布指南。
Markdown
我们遵循 Ciro Santilli 的 Markdown 风格指南。
文档
请参阅专门的 文档风格指南。
良好实践指南
良好实践示例展示了推荐的编码方式，并与应避免的做法进行比较。这些示例被标记为 “Bad” 或 “Good”。在 GitLab 开发指南中，展示案例时，建议采用 “先坏后好” 的策略。首先展示 “Bad” 实践（事情可能如何做，这通常仍然是可工作的代码），然后展示事情应该如何做得更好，使用 “Good” 示例。这通常是同一代码的改进版本。
在提供示例时，请考虑以下指南：
- 首先，提供 “Bad” 示例，然后是 “Good” 示例。
- 当只给出一个坏案例和一个好案例时，使用同一个代码块。
- 当提供多个坏案例或一个好案例时，为每个案例使用单独的代码块。在展示许多示例时，清晰的分隔有助于读者直接跳到好的部分。考虑提供解释（例如，注释或资源链接）说明为什么某种做法是不良实践。
- 更好和最佳案例可以视为好案例代码块的一部分。在同一个代码块中，每个前面加上注释：
# Better和# Best。
虽然坏-好方法适用于 GitLab 开发指南，但不要在用户文档中使用。对于用户文档，使用 Do 和 Don’t。示例请参见 Pajamas Design System。
Python
请参阅专门的 Python 开发指南。
其他
代码应用 美式英语 编写。