实用 Git 与 GitHub 设置用于真实项目

Source: Dev.to

为什么这种设置有效

• 对初学者友好
• 可扩展至团队使用
• 规则最少，清晰度最高
• 已在真实生产项目中使用

分支策略（简洁而强大）

main        → production‑ready code
develop     → active development
feature/*   → new features
bugfix/*   → bug fixes
hotfix/*   → urgent production fixes

示例

feature/user-login
bugfix/cart-total
hotfix/payment-crash

为什么不使用复杂的 GitFlow？

• 更少的分支需要管理
• 更快的上手
• 更少的混乱

提交信息约定

使用轻量级的约定格式：

type(scope): short description

常用类型

• feat – 新特性
• fix – bug 修复
• refactor – 内部改进
• docs – 文档
• test – 测试
• chore – 工具 / 配置

示例

feat(auth): add OTP login
fix(cart): correct total price
refactor(api): simplify serializer

GitHub 标签（最小且实用）

类型

• type: bug
• type: feature
• type: enhancement
• type: refactor

优先级

• priority: high
• priority: medium
• priority: low

状态

• status: ready
• status: in-progress
• status: blocked
• status: needs-review

严重程度（针对错误）

• severity: critical
• severity: major
• severity: minor

问题模板

错误报告

描述

重现步骤

预期行为

实际行为

环境

### 功能请求

```markdown

## 问题

## 方案建议

## 替代方案

It looks like the text you’d like translated didn’t come through. Could you please resend the content you want translated into Simplified Chinese? I’ll keep the source link (if any) exactly as it is and preserve all formatting. Thank you!

## 拉取请求模板

```markdown

这个 PR 做了什么？

相关问题

关闭 #123

更改内容

如何测试

Checklist

• 代码符合标准
• 已添加/更新测试
• 没有破坏性更改

代码审查与分支保护

规则

• 禁止直接推送到 main
• 必须提交拉取请求
• 至少 1 次批准
• 必须通过状态检查

这些规则确保 在不减慢开发速度的情况下保持质量。

使用 GitHub Actions 自动化

基本 CI 工作流

创建 .github/workflows/ci.yml：

name: CI

on:
  pull_request:
  push:
    branches: [main, develop]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 18

      - name: Install dependencies
        run: npm install

      - name: Run tests
        run: npm test

这能为你带来什么

• 如果测试失败，PR 会自动标记为失败
• 不需要人为记得运行测试
• main 分支更干净

独立开发者 vs 团队设置

独立开发者（推荐）

• 分支：main，feature/*
• 标签：类型 + 优先级
• 拉取请求（PR）：可选，但推荐
• 持续集成（CI）：是（不可协商）

为什么？ 即使是独立开发者也会忘记上下文。这可以保持历史记录的整洁。

小团队（2–5 名开发者）

• 完整的分支策略
• 强制拉取请求
• 用于状态和严重程度的标签
• 合并前必须通过 CI

结果： 减少混乱，降低 bug 数量，加快审查速度。

大型团队

• 添加 CODEOWNERS
• 需要 2 次批准
• 添加 lint 和安全检查
• 自动发布说明

README 结构

# Project Name

描述

技术栈

设置

脚本

贡献

许可证

常见错误需避免

• 标签过多
• 直接提交到 main
• 提交信息模糊
• 没有自动化
• 没有 PR 模板

最后思考

一个好的 Git 与 GitHub 设置应该 隐身于后台，并让你专注于构建。

此设置具备：

• 易用
• 可扩展
• 经生产验证