长期分支同步禁用git pull，应先fetch再按需merge或rebase；hotfix须从对应tag创建并双目标合入；release分支按EOL、PR活跃度、6个月无推送三指标归档。
长期分支的同步不能靠 git pull
git pull 是 git fetch + git merge 的快捷组合，对长期分支（如 release/1.2.x、main）来说，直接 git pull 容易引入非预期的合并提交，污染线性历史，也掩盖真实变更来源。长期分支需要的是「可控拉取 + 显式整合」。
正确做法是分两步：
- 先用
git fetch origin release/1.2.x获取远程最新状态，不触碰当前工作区 - 再根据策略选择
git merge origin/release/1.2.x（保留合并记录）或git rebase origin/release/1.2.x（仅当该分支纯属你个人维护且无共享协作者） - 若分支已开启保护（如 GitHub 的 branch protection），
git push前必须通过 CI 检查和 PR 审核，此时本地同步只是为准备 PR 做基础
如何安全地向长期分支合入修复（hotfix）
hotfix 必须从对应 tag 创建，而不是从 main 或 develop 拉取 —— 否则会把不该带上的新功能一起带进去。比如线上运行的是 v1.2.3，热修复分支应这样诞生：
git checkout -b hotfix/1.2.4-db-connection v1.2.3 # 修改、测试、提交 git push origin hotfix/1.2.4-db-connection
合入时注意目标分支：该 hotfix 应同时合入两个地方：
-
release/1.2.x（用于紧急发布 1.2.4） -
main（确保后续大版本也包含此修复）
但不能反向操作：不要把 main 的提交 cherry-pick 到 release/1.2.x，除非你能 100% 确认它不依赖任何 main 特有逻辑 —— 这种判断成本远高于从 tag 重建分支。
openclaw-gitcode-pr-monitor
下载
监控一个或多个 GitCode 仓库的 PR，通过 OpenClaw Gateway 自动执行 AI 审查，发布 PR 评论，并发送钉钉和企业微信通知。
长期分支的清理与归档时机
长期分支不是永久存在的。是否该停更或归档，取决于三个硬指标：
- 对应版本是否已 EOL（End-of-Life）：例如
release/1.1.x在官方支持周期结束后，就该标记为archive/1.1.x - 是否有活跃的 PR 或 issue 关联该分支：用
gh pr list --base release/1.1.x（GitHub CLI）或 GitLab 对应 API 检查 - 最近一次推送是否超过 6 个月：可用
git log -1 --format="%ai" release/1.1.x查看最后提交时间
归档不是删除，而是重命名 + 加只读保护：git branch -m release/1.1.x archive/1.1.x，然后在远端平台关闭该分支的推送权限。
为什么 develop 分支不适合当长期分支来维护
develop 是集成预发布代码的中转站，天然不稳定。把它当成长期分支去维护，会导致：
- 无法区分“已验证可发布”和“待验证”的提交，tag 失去可信度
- CI 流水线难以配置：测试环境不知道该部署哪个 commit 才算“稳定”
- 团队成员误以为
develop可直接上线，跳过 release 分支流程
真正该长期维护的是 main（或 master）和各 release/* 分支。它们的提交必须经过完整测试链，且每次合并都应附带关联的 issue 或 PR 编号 —— 这不是形式主义，是事后审计的唯一依据。
