长期分支同步禁用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 编号 —— 这不是形式主义，是事后审计的唯一依据。