spatie-version-control

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Spatie Version Control Guidelines

Spatie版本控制指南

Overview

概述

Apply Spatie's Git and version control conventions for consistent repository management.
遵循Spatie的Git和版本控制规范,实现一致的仓库管理。

When to Activate

适用场景

  • Activate this skill when creating commits, branches, or pull requests.
  • Activate this skill when naming new repositories.
  • Activate this skill when deciding on branching or merging strategies.
  • 当创建提交、分支或拉取请求时启用此技能。
  • 当命名新仓库时启用此技能。
  • 当确定分支或合并策略时启用此技能。

Scope

适用范围

  • In scope: Git operations, repository naming, branch naming, commit messages, merge strategies.
  • Out of scope: Code style, deployment pipelines, CI/CD configuration.
  • 包含:Git操作、仓库命名、分支命名、提交消息、合并策略。
  • 不包含:代码风格、部署流水线、CI/CD配置。

Repository Naming

仓库命名

Site source code

站点源代码

Use the main domain name in lowercase, without
www
:
  • Good:
    spatie.be
  • Bad:
    https://www.spatie.be
    ,
    www.spatie.be
    ,
    Spatie.be
使用小写的主域名,不带
www
  • 正确示例:
    spatie.be
  • 错误示例:
    https://www.spatie.be
    ,
    www.spatie.be
    ,
    Spatie.be

Subdomains

子域名

Include the subdomain in the repo name:
  • Good:
    guidelines.spatie.be
  • Bad:
    spatie.be-guidelines
仓库名称中包含子域名:
  • 正确示例:
    guidelines.spatie.be
  • 错误示例:
    spatie.be-guidelines

Packages and other projects

包及其他项目

Use kebab-case:
  • Good:
    laravel-backup
    ,
    spoon
  • Bad:
    LaravelBackup
    ,
    Spoon
使用短横线分隔命名(kebab-case):
  • 正确示例:
    laravel-backup
    ,
    spoon
  • 错误示例:
    LaravelBackup
    ,
    Spoon

Branches

分支

Initial development

初始开发阶段

  • Maintain
    main
    and
    develop
    branches.
  • Commit through
    develop
    , not directly to
    main
    .
  • Feature branches are optional; if used, branch from
    develop
    .
  • 维护
    main
    develop
    分支。
  • 提交代码到
    develop
    分支,而非直接提交到
    main
  • 功能分支为可选;若使用,需从
    develop
    分支创建。

Live projects

上线项目

  • Delete the
    develop
    branch.
  • All commits to
    main
    must come through feature branches.
  • Prefer squashing commits on merge.
  • 删除
    develop
    分支。
  • 所有提交到
    main
    的代码必须来自功能分支。
  • 合并时优先选择压缩提交(squash commits)。

Branch naming

分支命名

  • Use lowercase letters and hyphens only.
  • Good:
    feature-mailchimp
    ,
    fix-deliverycosts
    ,
    updates-june-2016
  • Bad:
    feature/mailchimp
    ,
    random-things
    ,
    develop
  • 仅使用小写字母和短横线。
  • 正确示例:
    feature-mailchimp
    ,
    fix-deliverycosts
    ,
    updates-june-2016
  • 错误示例:
    feature/mailchimp
    ,
    random-things
    ,
    develop

Commits

提交

Message format

消息格式

  • Always use present tense.
  • Good:
    Update deps
    ,
    Fix vat calculation in delivery costs
  • Bad:
    wip
    ,
    commit
    ,
    a lot
    ,
    solid
  • 始终使用一般现在时
  • 正确示例:
    Update deps
    ,
    Fix vat calculation in delivery costs
  • 错误示例:
    wip
    ,
    commit
    ,
    a lot
    ,
    solid

Granularity

提交粒度

  • Prefer small, focused commits over large ones.
  • Use
    git add -p
    for interactive staging to create granular commits.
  • 优先选择小型、聚焦的提交,而非大型提交。
  • 使用
    git add -p
    进行交互式暂存,以创建粒度更细的提交。

Merging

合并

  • Rebase regularly to reduce merge conflicts.
  • For deploying feature branches: use
    git merge <branch> --squash
    .
  • If push is denied: use
    git rebase
    (not merge).
  • 定期执行rebase以减少合并冲突。
  • 部署功能分支时:使用
    git merge <branch> --squash
    命令。
  • 若推送被拒绝:使用
    git rebase
    (而非merge)。

Pull Requests

拉取请求

  • Optional but useful for peer review, merge validation, and historical reference.

  • 可选操作,但有助于同行评审、合并验证和历史记录留存。