确保 main 是干净、稳定的h2

1
git checkout main
2
git pull origin main

owner 情况下：

• origin 就是「官方仓库」

• main 上的代码 = 当前对外状态

从 main 新建 feature 分支h2

1
git checkout -b feature/my-new-feature

命名建议（你作为 owner，要立规范）：

• feature/*
• fix/*
• chore/*
• docs/*

在 feature 分支上开发（和普通开发完全一样）h2

1
# 写代码
2
git status
3
git add .
4
git commit -m "feat: add xxx support"

✔ 可以拆成多个小 commit
✔ 提交信息越清晰，越方便 code review（哪怕 reviewer 是未来的你）

同步 main（当有其他人 push 或 PR 合并时）h2

如果你在开发期间：

• 合并了别人的 PR
• 或 main 被 CI 自动更新

推荐方式：rebase mainh3

1
git fetch origin
2
git rebase origin/main

含义：

把你的 feature 提交「挪到最新 main 后面」

feature 开发完成 → 发 PR（哪怕是你自己）h2

成熟项目一定是：owner 给自己提 PR

为什么？h3

• CI 会跑
• 能触发 Review 规则
• 强制你写清楚改动说明
• 防止“脑补正确”

1
base: main
2
compare: feature/my-new-feature

你可以：

• 自己 approve
• 或要求至少 1 个 reviewer

PR 通过后再合并到 mainh2

合并方式（强烈建议）：

Squash and merge（小 feature）h3

• main 历史干净
• 一个 PR = 一个 commit

Rebase and merge（大 feature）h3

• 保留 feature 内部结构
• main 仍然线性

❌ 不推荐 Create a merge commit（除非你明确要保留分支结构）

owner 额外应该注意什么h2

保护 main 分支（非常重要）h3

GitHub → Settings → Branch protection rules：

• 禁止直接 push main
• 必须 PR
• 必须 CI 通过
• 至少 1 个 review（可以是你自己）

写 CONTRIBUTING.mdh3

明确告诉别人：

• 不要直接改 main
• 使用 feature 分支
• 是否要求 rebase
• commit message 规范

定义 commit message 规范h3

例如：

1
feat:
2
fix:
3
docs:
4
refactor:
5
test:
6
chore:

为以后自动发版（semantic release）打基础。

CI 只对 PR 和 main 跑h3

避免 feature 分支浪费资源。

release ≠ mainh3

1
main        ← 开发主线
2
release/*   ← 发布分支
3
hotfix/*    ← 紧急修复