核心用法
GitFlow 是一款面向开发者的 OpenClaw 自动化技能，核心目标是打通本地代码提交与远程 CI/CD 状态监控的最后一环。其典型工作流为：开发者在本地完成代码变更后，GitFlow 可自动或按需推送至远程仓库，随后主动触发并轮询 GitHub Actions 或 GitLab CI 的管道执行状态，最终将构建结果、日志链接及失败详情实时反馈至终端。
技能深度集成 gh 与 glab 两大官方 CLI 工具，提供完整的状态查询、实时追踪、日志获取及失败重跑能力。此外，还附带可复用的 Shell 包装脚本与 Git 别名配置，让开发者无需记忆冗长命令即可实现"推送即监控"的一体化体验。
显著优点
- 跨平台统一：同时支持 GitHub 与 GitLab 两大主流代码托管平台，覆盖绝大多数企业开发场景。
- 零配置感知：通过解析远程仓库 URL 自动识别平台类型，无需手动指定提供商。
- 实时反馈闭环：
gh run watch与glab ci status --live实现阻塞式实时监控，开发者无需频繁刷新浏览器。 - 可扩展钩子机制：提供的
git-pushflow脚本与 Git 别名方案易于二次定制，可嵌入团队标准化工作流。
潜在局限
- 依赖外部 CLI：必须预先安装并认证
gh和glab，且需持有对应仓库的 API 访问令牌，初始环境配置成本较高。 - 平台检测鲁棒性有限：URL 匹配逻辑基于简单字符串包含判断（如
*github.com*、gitlab），可能误判私有部署实例或镜像仓库。 - 无原生失败通知：缺少桌面推送、Slack 集成等主动通知机制，开发者需保持终端聚焦。
- Git 钩子限制：Git 本身无
post-push钩子，技能采用包装脚本方案，无法拦截原生git push行为。
适合人群
- 高频使用 GitHub/GitLab CI 的全栈与 DevOps 工程师
- 追求终端一体化、厌恶浏览器上下文切换的资深开发者
- 需要快速为团队标准化推送后监控流程的技术负责人
常规风险
- 令牌泄露风险：脚本执行依赖持久化的 CLI 认证令牌，若在共享环境或日志中暴露可能引发未授权仓库访问。
- 管道敏感信息暴露：日志查看功能可能输出构建过程中的环境变量、密钥等敏感内容，需在受信任终端使用。
- 资源消耗：实时轮询模式在长时间构建场景下持续占用终端会话，且对平台 API 产生额外调用频率。