specsfy-specialist-gitflow

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Gitflow

Quando usar

适用场景

Acionar quando a pessoa pedir explicitamente o modelo Gitflow (branches
```
main
```
/
```
master
```
,
```
develop
```
,
```
feature/*
```
,
```
release/*
```
,
```
hotfix/*
```
) ou quando já existir configuração
```
git flow
```
(
```
git config --get-regexp '^gitflow\.'
```
) ou instrução do projeto declarando essa escolha.
Acionar também para nomear, sequenciar ou fechar uma branch
```
feature/
```
,
```
release/
```
ou
```
hotfix/
```
dentro de um projeto que já declarou Gitflow como estratégia de branch.
Não acionar para propor Gitflow a um projeto que não pediu isso — a escolha do modelo de branch é decisão explícita de quem conduz o projeto, nunca inferida pela presença de uma branch chamada
```
develop
```
ou pelo volume de branches abertas.
Não acionar para resolver um conflito já em andamento (
```
$specsfy-specialist-merge-conflict-resolution
```
) nem para desenhar o pipeline ou a promoção de artefato entre ambientes (
```
$specsfy-specialist-delivery-engineering
```
) — aqui o foco é a topologia e a política das branches, não a resolução textual nem a entrega.

当用户明确要求使用Gitflow模型（
```
main
```
/
```
master
```
、
```
develop
```
、
```
feature/*
```
、
```
release/*
```
、
```
hotfix/*
```
分支），或项目已配置
```
git flow
```
（
```
git config --get-regexp '^gitflow\.'
```
），或有明确文档声明采用该模型时触发。
当已声明将Gitflow作为分支策略的项目中，需要对
```
feature/
```
、
```
release/
```
或
```
hotfix/
```
分支进行命名、排序或关闭操作时也可触发。
请勿为未主动要求的项目提议使用Gitflow——分支模型的选择是项目负责人的明确决策，绝不能仅凭存在名为
```
develop
```
的分支或分支数量就推断采用Gitflow。
请勿用于解决已发生的冲突（
```
$specsfy-specialist-merge-conflict-resolution
```
），也不要用于设计流水线或环境间的制品推送流程（
```
$specsfy-specialist-delivery-engineering
```
）——此处重点是分支的拓扑结构和策略，而非文本冲突解决或交付流程。

Fluxo

流程

Confirmar que a pessoa pediu Gitflow explicitamente, ou apontar a configuração/instrução existente que já declara essa escolha, antes de aplicar qualquer convenção — nunca presumir Gitflow a partir da estrutura do repositório.
Verificar o estado real das branches (
```
git branch -a
```
,
```
git config --get-regexp '^gitflow\.'
```
) para saber se
```
main
```
/
```
master
```
e
```
develop
```
já existem e se a nomenclatura das branches auxiliares já diverge do padrão adotado.
Definir com a pessoa os nomes das branches permanentes (
```
main
```
de produção,
```
develop
```
de integração) e os prefixos das branches de vida curta (
```
feature/
```
,
```
release/
```
,
```
hotfix/
```
,
```
support/
```
quando aplicável).
Registrar a decisão como regra confirmada do projeto (
```
$specsfy-aux-rules
```
grava em
```
.specsfy/RULES.md
```
), incluindo prefixos, branch-alvo de cada tipo e política de merge — não deixar a convenção apenas verbal.
Orientar a abertura, a integração e o fechamento de cada tipo de branch:
```
feature/*
```
parte de e volta para
```
develop
```
;
```
release/*
```
parte de
```
develop
```
e vai para
```
main
```
e
```
develop
```
;
```
hotfix/*
```
parte de
```
main
```
e vai para
```
main
```
e
```
develop
```
; sempre com
```
merge --no-ff
```
.
Coordenar a tag de versão no merge de
```
release/*
```
ou
```
hotfix/*
```
em
```
main
```
, alinhando com a estratégia de versionamento já adotada pelo projeto (semver ou outra).
Verificar que
```
develop
```
recebeu de volta toda correção aplicada em
```
release/*
```
ou
```
hotfix/*
```
antes de considerar o ciclo fechado — divergência aqui reaparece como regressão no próximo release.

在应用任何约定之前，确认用户已明确要求使用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/*
```
中应用的修复——此处的分歧会在下一次发布时以回归问题的形式重现。

Padrões

标准

Usar
```
git merge --no-ff
```
para toda integração de
```
feature/*
```
,
```
release/*
```
e
```
hotfix/*
```
— merge fast-forward apaga o registro de que aquela branch existiu, do qual a auditoria de release do Gitflow depende.
Nomear com prefixo consistente e o mesmo separador em todo o projeto (
```
feature/<slug>
```
,
```
release/<versao>
```
,
```
hotfix/<versao-ou-slug>
```
); não misturar convenções (
```
feature-x
```
e
```
feature/y
```
no mesmo repositório).
Fazer
```
release/*
```
e
```
hotfix/*
```
partirem exatamente do commit de
```
develop
```
ou
```
main
```
correspondente, sem cherry-pick seletivo de commits ainda não integrados.
Aplicar em
```
release/*
```
somente correção de bug, texto, documentação e preparação de release (changelog, versão) — funcionalidade nova não entra numa branch de release já aberta; volta para a próxima
```
feature/*
```
.
Fechar todo
```
hotfix/*
```
mesclando em
```
main
```
(com tag) e em
```
develop
```
(ou na
```
release/*
```
aberta, se houver uma) na mesma operação — hotfix que só chega em
```
main
```
desaparece do próximo release.
Apagar a branch de vida curta (
```
feature/*
```
,
```
release/*
```
,
```
hotfix/*
```
) depois do merge confirmado nos dois destinos — branch finalizada e não apagada convida retrabalho sobre código já integrado.

所有
```
feature/*
```
、
```
release/*
```
和
```
hotfix/*
```
的集成均使用
```
git merge --no-ff
```
——快进合并会抹去该分支存在的记录，而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
```
的热修复会在下一次发布中消失。
在确认合并到两个目标分支后，删除短期分支（
```
feature/*
```
、
```
release/*
```
、
```
hotfix/*
```
）——已完成但未删除的分支会导致在已集成的代码上重复工作。

Antipadrões

反模式

Push direto ou merge fast-forward em
```
main
```
/
```
develop
```
sem passar por
```
feature/
```
,
```
release/
```
ou
```
hotfix/
```
: quebra a rastreabilidade que justifica adotar Gitflow em vez de um modelo mais simples.
Funcionalidade nova adicionada dentro de uma
```
release/*
```
já aberta "para aproveitar a janela": aumenta o escopo testado depois do corte e atrasa a liberação sem necessidade.
Hotfix mesclado apenas em
```
main
```
, deixando
```
develop
```
divergente: a próxima
```
release/*
```
cortada de
```
develop
```
reintroduz o bug já corrigido em produção.
Adotar Gitflow num projeto com deploy contínuo várias vezes ao dia: a sobrecarga de branches longas de
```
release
```
/
```
hotfix
```
conflita com entrega contínua; nesse contexto, avalie com a pessoa se GitHub Flow ou trunk-based atende melhor antes de aplicar Gitflow por hábito.
Confundir "temos uma branch chamada develop" com "o projeto usa Gitflow": sem a política de merge, os prefixos e o ciclo de release completos, é apenas uma branch com esse nome, não o modelo.

不经过
```
feature/
```
、
```
release/
```
或
```
hotfix/
```
分支，直接向
```
main
```
/
```
develop
```
推送或进行快进合并：破坏了采用Gitflow而非更简单模型的核心价值——可追溯性。
为了“利用窗口”在已开启的
```
release/*
```
分支中添加新功能：增加了截版后需要测试的范围，毫无必要地延迟发布。
热修复仅合并到
```
main
```
，导致
```
develop
```
分支出现分歧：从
```
develop
```
分支创建的下一个
```
release/*
```
会重新引入已在生产环境修复的bug。
在每天多次持续部署的项目中采用Gitflow：
```
release
```
/
```
hotfix
```
长分支带来的额外负担与持续交付冲突；这种情况下，应先与用户评估GitHub Flow或trunk-based是否更适用，不要仅凭习惯就应用Gitflow。
将“我们有一个名为develop的分支”等同于“项目使用Gitflow”：没有完整的合并策略、前缀规则和发布/热修复周期的话，这只是一个同名分支，并非Gitflow模型。

Validação

验证

```
git log --graph --oneline --all
```
(ou
```
git log --first-parent main
```
) mostrando os merges
```
--no-ff
```
de cada
```
feature/
```
,
```
release/
```
ou
```
hotfix/
```
como commits de merge identificáveis, não commits lineares indistinguíveis.
```
git branch -a --merged develop
```
e
```
git branch -a --merged main
```
conferidos antes de apagar uma branch de vida curta, garantindo que o merge realmente aconteceu nos dois destinos esperados.

Tag de versão presente em

main

para cada

release/*

hotfix/*

fechado (

git tag --contains <commit-do-merge>

), e a mesma correção presente em

develop

(

git log develop --oneline | grep <commit>

ou equivalente).

```
.specsfy/RULES.md
```
(ou instrução equivalente do projeto) registrando a convenção de nomes e a política de merge, revisitada por
```
$specsfy-aux-rules
```
quando alguém a violar.
Não declarar "o projeto segue Gitflow" apenas porque existe uma branch
```
develop
```
; a evidência exige prefixos consistentes, merges
```
--no-ff
```
rastreáveis e o ciclo de
```
release
```
/
```
hotfix
```
fechado nos dois destinos.

使用
```
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
```
双目标合并周期作为证据。

specsfy-specialist-gitflow

Original

Translation

Gitflow

Gitflow

Quando usar

适用场景

Fluxo

流程

Padrões

标准

Antipadrões

反模式

Validação

验证

Skills relacionadas

相关技能