分支保护规则让开源贡献新手头疼的典型场景

背景是给 He4rt 社区的 4noobs 项目贡献了不到 50 行的 README 修改，包括更换 badge、调整 Logo 对比度、增加目录索引。本来预计十分钟就能完成，但因为在分支保护规则上的不熟悉，导致本地反复创建和删除分支，最终花费了两个小时。核心问题并非 Git 命令不熟练，而是对 main 分支的推送感到焦虑，以及不了解远程仓库的分支保护规则细节。

几个关键的操作失误：

• 误用终端提供的 PR 链接：当本地执行 git push origin fix/readme-typo 后，终端显示的 Create a pull request 链接被误解为点击即可完成合并。实际上，这个链接只是引导到 GitHub 网站手动创建 pull request，push 仅将本地分支同步到远程，必须通过网站流程提交合并请求。_pull request_ 是由 reviewer 审核批准后才真正合并到 main 分支。

• 分支历史不同步导致冲突：在分支保护规则中启用了「Require a pull request before merging」和「Require approvals」的情况下，直接从较旧的 main 分支创建新分支，未执行 git pull --rebase upstream main 同步。由于 upstream 主分支已经合并了其他提交，导致新分支历史断裂，与 main 分支无共同提交记录。

提交规范和项目流程的忽视：

• 提交信息格式错误：由于 Commit message 未遵循 Conventional Commits 规范，写成了简单的 update readme，被 CI 中的 commitlint 拒绝。项目要求使用 type: description 格式，例如 docs: update README badge and add TOC。修改提交信息三次后才通过，git commit --amend 成为常用操作。

• 忽视贡献模板：.github 目录下的 PULL_REQUEST_TEMPLATE.md 和 CONTRIBUTING.md 未被仔细阅读。提交 PR 时未按模板要求填写「Related issue」、「Type of change」、「Checklist」三个部分，导致 reviewer 评论要求补充。贡献指南中的模板是必须遵循的实际要求。

正确的操作流程总结：

# 1. 同步 upstream 主分支最新状态
git fetch upstream
git checkout main
git rebase upstream/main

# 2. 创建新分支，命名需符合项目规范：type/简短描述
git checkout -b docs/readme-badge-and-toc

# 3. 修改文件，分步提交，提交信息严格按规范
git add README.md
git commit -m "docs: replace outdated badge and add table of contents"

# 4. 推送分支并关联 upstream
git push -u origin docs/readme-badge-and-toc

# 5. 通过终端提供的链接创建 PR，填写模板要求的信息
#    - What: 具体修改内容
#    - Why: 修改的必要性
#    - Checklist: 完成测试、文档更新、breaking change 说明

团队协作的关键在于流程的严格遵守：

在合并成功后，CI 环境全绿且 reviewer 赞同，才真正理解协作的核心原则：不擅自修改他人分支，不污染 main 分支，提交信息清晰让审核者高效工作。分支保护规则、提交模板、代码检查等机制，是将协作从依赖个人自觉转变为依赖标准化流程。未来再参与开源项目贡献时，会先确认分支状态，但不再需要对着「Create pull request」按钮犹豫。