GitHub 分支与协作
分支的核心作用是在开发和审查期间隔离变更。仓库的默认分支（Default Branch）通常是集成的目标；至于它叫什么名字、是否可直接部署，完全由项目决定，Git 本身没有强制规定。
分支工作流
git fetch origin
git switch -c fix/short-description origin/main
# edit and test
git add path/to/file
git commit -m "Fix the short description"
git push -u origin fix/short-description
请将 main 替换为仓库实际的默认分支名。从功能分支发起 Pull Request (PR) 时，要讲清楚为什么要改、验证了哪些内容，并确保无关改动不混入同一个 diff 中。
代码没写完也可以先开 PR，记得标记为 Draft（草稿）。谁有权批准或合并，取决于分支保护规则和仓库策略。大多数团队要求必须由作者以外的人进行审批。
审查与合并
高质量的审查应关注：行为逻辑、测试覆盖、安全边界、兼容性以及是否有冗余改动。对于讨论中的问题，要么解决，要么解释为什么不需要改。合并前，如果基准分支有更新，务必同步最新代码并重新运行受影响的检查。
仓库可能采用 Merge Commit、Squash Merge 或 Rebase 策略。请遵循团队惯例，默认不要重写共享历史。功能分支合并后若不再需要，可以删除；提交记录依然保留在仓库历史中。
Fork 工作流
如果你没有权限直接向目标仓库推送分支，就需要创建 Fork，并配置两个远程仓库：
git clone https://github.com/YOU/PROJECT.git
cd PROJECT
git remote add upstream https://github.com/OWNER/PROJECT.git
git fetch upstream
这里 origin 指向你的 Fork，upstream 指向源仓库。为了刷新本地默认分支，避免依赖模糊的 pull 设置，执行以下操作：
git switch main
git fetch upstream
git merge --ff-only upstream/main
git push origin main
然后基于刷新后的默认分支创建贡献分支。如果上游分支不叫 main，请使用其实际名称。
推送前检查
- 阅读仓库的贡献指南及代理说明。
- 检查
git status、未暂存差异（unstaged diff）及已暂存差异（staged diff）。 - 运行能捕获变更潜在失败的最小测试集。
- 确认提交中不包含凭证、私有数据、生成产物或无关编辑。
- 仅推送到预期的远程仓库和分支。
Fork 保留上游项目的许可证义务。贡献权限与审查规则源自该项目本身，而非 Fork 按钮的存在。