推荐用feature/develop/main三分支模型，配合强制pr流程；因git flow的release/hotfix分支在持续交付中增加负担，且易导致develop与main不同步、绕过代码审查等问题。
推荐用 feature/develop/main 三分支模型，配合强制 PR（Pull Request）流程。这不是“最全”的方案，而是当前中小团队落地成本最低、冲突可预见性最强、权限和发布节奏最容易管控的组合。
为什么不用 Git Flow？
Git Flow 的 release 和 hotfix 分支在持续交付场景下反而增加负担：每次发版都要切分支、合并两次、删分支，而多数现代项目（尤其是 Web/APP 后端）已转向按需发布、小步快跑。实际项目中，release/* 分支常被闲置或误用，反而导致 develop 和 main 同步滞后、环境不一致。更关键的是，Git Flow 默认不约束 PR 流程，容易出现直接 git push 到 develop 的情况——这正是团队协作混乱的起点。
feature 分支必须从 develop 拉，且命名带前缀
这是避免基线漂移的核心动作。如果某人从过期的 develop 创建 feature/login，开发一周后提交 PR，极大概率要面对大量冲突；而若他本地没及时 git pull origin develop，冲突会直接甩给审核者。
监控一个或多个 GitCode 仓库的 PR，通过 OpenClaw Gateway 自动执行 AI 审查，发布 PR 评论，并发送钉钉和企业微信通知。
-
git checkout develop && git pull origin develop是创建前必做动作 - 分支名必须用
feature/xxx、bugfix/yyy等前缀，便于 CI/CD 自动识别和清理 - 禁止使用
feature1、test-branch这类无意义命名——它会让git branch -a输出变成不可读的噪音 - 远程
feature/*分支合并进develop后，应立刻执行git push origin --delete feature/login
develop 分支必须受保护，禁止直接 push
只要允许 git push origin develop，就等于开放了“绕过代码审查”的后门。所有对 develop 的变更，必须通过 PR 触发 CI 检查（如 lint、单元测试）、至少一人 approve，再由系统自动合并。
- Gitee/GitHub 上需开启
Protect this branch，勾选 “Require a pull request before merging” 和 “Include administrators” - 本地误操作
git push origin develop会被拒绝，报错类似：! [remote rejected] develop -> develop (protected branch hook declined) - 如果真需要紧急合入，应走 hotfix 流程：从
main拉hotfix/xxx→ 修复 → PR 合入main和develop（顺序不能反）
本地看不到远程已删分支？先 fetch 再 prune
git branch -a 显示已删除的远程分支（如 remotes/origin/feature/old），不是 bug，是 Git 的默认行为：它只记录你上次 fetch 时看到的远程状态，不会自动清理过期引用。
- 手动清理：运行
git fetch --prune origin（或简写git fetch -p） - 设为默认行为：执行
git config --global fetch.prune true，此后所有git fetch都自动 prune - 注意：prune 不影响本地同名分支，只删
remotes/origin/xxx这类远程跟踪引用
真正容易被忽略的是：很多团队把 git pull 当成万能同步命令，但它默认只拉当前分支，不会更新其他远程分支列表——所以 git pull 后仍可能看到陈旧的 origin/feature/*，必须显式 fetch -p。
