specsfy-specialist-gitflow

Name: specsfy-specialist-gitflow
Author: promovaweb

github.com/promovaweb开发87196 次安装1 周前更新

关于 specsfy-specialist-gitflow

面向明确采用 Gitflow 分支模型的项目的专项技能，指导分支命名、合并、发布标签和分支周期收尾。它不会仅凭仓库结构推断项目采用 Gitflow。

复制下面的命令，在终端中运行。

$npx skills add https://github.com/promovaweb/specsfy --skill specsfy-specialist-gitflow

安装后在 Claude Code 中输入/specsfy-specialist-gitflow确认已加载。

附带文件agents/openai.yamlreferences/standards.md

当用户明确要求采用 Gitflow 模型（分支 main/master、develop、feature/*、release/*、hotfix/*），或已有 git flow 配置（git config --get-regexp '^gitflow\.'），或项目说明中声明了这一选择时，使用此流程。
对于已声明采用 Gitflow 作为分支策略的项目，当需要命名、排序或关闭 feature/、release/ 或 hotfix/ 分支时，也使用此流程。
如果项目没有提出要求，不要主动为其推荐 Gitflow——分支模型的选择必须由项目负责人明确决定，不能仅凭存在名为 develop 的分支或开放分支的数量来推断。
不要用此流程解决已发生的冲突（$specsfy-specialist-merge-conflict-resolution），也不要用它设计流水线或不同环境间的制品晋级流程（$specsfy-specialist-delivery-engineering）——这里关注的是分支拓扑和策略，而不是文本冲突的解决或交付。

在应用任何约定之前，确认用户明确要求采用 Gitflow，或指出现有配置／说明中已声明了这一选择——绝不能根据仓库结构擅自推断采用 Gitflow。
检查分支的实际状态（git branch -a、git config --get-regexp '^gitflow\.'），了解 main/master 和 develop 是否已存在，以及辅助分支的命名是否已偏离既定标准。
与用户确定永久分支的名称（生产分支 main、集成分支 develop）以及短期分支的前缀（适用时包括 feature/、release/、hotfix/、support/）。
将决定记录为项目已确认的规则（$specsfy-aux-rules 会写入 .specsfy/RULES.md），包括前缀、每种分支的目标分支以及合并策略——不要只口头约定。
指导各类分支的创建、集成和关闭：feature/* 从 develop 创建并合回 develop；release/* 从 develop 创建并合入 main 和 develop；hotfix/* 从 main 创建并合入 main 和 develop；始终使用 merge --no-ff。
将 release/* 或 hotfix/* 合入 main 时协调版本标签，并与项目现行的版本策略（semver 或其他策略）保持一致。
在认为周期已结束之前，确认 develop 已收到 release/* 或 hotfix/* 中应用的所有修复——否则分支差异会在下一次发布中再次引发回归。

集成所有 feature/*、release/* 和 hotfix/* 时使用 git merge --no-ff——fast-forward 合并会抹去该分支曾经存在的记录，而 Gitflow 的发布审计依赖这一记录。
使用统一的前缀和分隔符命名整个项目的分支（feature/<slug>、release/<versao>、hotfix/<versao-ou-slug>）；不要在同一仓库中混用约定（例如 feature-x 和 feature/y）。
让 release/* 和 hotfix/* 严格从对应的 develop 或 main 提交创建，不要 cherry-pick 尚未集成的提交。
在已创建的 release/* 分支中，只应用 bug 修复、文本和文档更改，以及发布准备工作（变更日志、版本）；不要加入新功能，应将其留给下一个 feature/*。
关闭每个 hotfix/* 时，都要在同一操作中将其合入 main（并添加标签）和 develop（如果有已打开的 release/*，则也要合入该分支）——只合入 main 的 hotfix 会从下一次发布中丢失。
确认已合入两个目标分支后，删除短期分支（feature/*、release/*、hotfix/*）——已完成却未删除的分支容易导致对已集成代码的重复工作。

未经 feature/、release/ 或 hotfix/，直接推送或快进合并到 main/develop：这会破坏可追溯性，而可追溯性正是采用 Gitflow 而不是更简单模型的理由。
为了“赶上窗口期”，在已开启的 release/* 中添加新功能：这会扩大切分后需要测试的范围，并无谓地延迟发布。
仅将 hotfix 合并到 main，导致 develop 出现分歧：下一次从 develop 切出的 release/* 会重新引入已在生产环境修复的 bug。
在每天多次持续部署的项目中采用 Gitflow：长期存在的 release/hotfix 分支会增加开销，与持续交付相冲突；在这种情况下，先与对方评估 GitHub Flow 或 trunk-based 是否更合适，再决定是否因习惯而采用 Gitflow。
把“有一个名为 develop 的分支”误认为“项目采用 Gitflow”：如果没有完整的合并策略、前缀和发布周期，它就只是一个碰巧叫这个名字的分支，而不是这种模型。

使用 git log --graph --oneline --all（或 git log --first-parent main），确认每个 feature/、release/ 或 hotfix/ 都有可识别的 --no-ff 合并提交，而不是无法区分的线性提交。
删除短期分支前，检查 git branch -a --merged develop 和 git branch -a --merged main，确保它确实已合并到预期的两个目标分支。
每个已完成的 release/* 或 hotfix/* 都应在 main 上有版本标签（git tag --contains <commit-do-merge>），并且同一修复也应存在于 develop（git log develop --oneline | grep <commit> 或等效命令）。
.specsfy/RULES.md（或项目中的等效说明）应记录命名约定和合并策略；有人违反时，应通过 $specsfy-aux-rules 重新审视。
不要仅因为存在 develop 分支就声称“项目遵循 Gitflow”；证据必须包括一致的前缀、可追溯的 --no-ff 合并，以及在两个目标分支上都已完成的 release/hotfix 周期。