Especialista Resolução de conflitos Git no Specsfy: guia

Quando usar

Acionar quando um git merge, git rebase ou git cherry-pick já está em andamento e há arquivos marcados como unmerged.
Não acionar para decidir qual branch deveria ter ganho a mudança em termos de produto — isso é decisão de quem pediu a integração, esta skill resolve o texto e o comportamento resultante, não reabre a decisão de negócio.
Combinar com $specsfy-specialist-code-review depois da resolução — o resultado combinado precisa da mesma revisão que qualquer diff novo teria.

Inspecionar o estado exato da operação (merge, rebase, cherry-pick), quais branches/commits estão envolvidos e quais arquivos estão unmerged.
Para cada hunk em conflito, recuperar a intenção de cada lado — o que a mudança tentava alcançar, não apenas o texto literal.
Classificar o conflito: textual (mesma linha, texto diferente), estrutural (mesma função/bloco reorganizado), semântico (sem marcador de texto, mas comportamento incompatível — ex.: assinatura mudou de um lado, caller não ajustado do outro) ou gerado (lockfile, arquivo build).
Construir o resultado que preserva as duas intenções quando elas são compatíveis — a resolução correta raramente é escolher um lado inteiro.
Quando as intenções são genuinamente incompatíveis, escolher pelo objetivo da integração (o que a spec/issue que motivou a integração pede) e registrar o trade-off descartado.
Remover todos os marcadores de conflito, validar sintaxe/parse do arquivo e rodar os checks focais (lint, typecheck) nos arquivos tocados.
Continuar a operação (git merge --continue/git rebase --continue) e executar a suíte de regressão relevante antes de publicar.

Nunca usar git checkout --ours/--theirs (ou resolução estratégica -X ours/-X theirs) em lote por conveniência — cada hunk pode ter uma resolução correta diferente, aplicar uma estratégia global descarta mudanças reais de um dos lados sem revisão.
Não editar um arquivo gerado (lockfile, build output, código gerado) sem atualizar a fonte que o gera e regenerar — editar o gerado diretamente diverge na próxima geração.
Preservar mudanças de schema, migrations, testes e contratos de API de ambos os lados quando elas não colidem de fato — um conflito num arquivo vizinho não autoriza descartar uma mudança de schema em outro.
Reavaliar imports, renomes e chamadas mesmo em arquivos sem marcador textual — um rename de um lado e um novo uso do nome antigo do outro lado não gera conflito Git, mas quebra em runtime ou build.
Não introduzir comportamento novo além do estritamente necessário para resolver o conflito — a resolução não é uma oportunidade de refactor.
Não usar --abort, force push ou reset destrutivo sem pedido explícito de quem está conduzindo a integração — a operação em andamento pode representar trabalho de resolução já feito por outra pessoa.
Conferir ao final que nenhum arquivo permanece unmerged e que o índice está limpo antes de continuar a operação.

Resolver “compilando” apenas: o arquivo perde os marcadores e builda, mas o comportamento resultante nunca foi comparado contra a intenção de nenhum dos dois lados — conflito semântico sobrevive disfarçado de resolvido.
Rebase que reescreve commits já publicados e compartilhados sem alinhar com quem mais trabalha sobre eles — quebra o histórico de outra pessoa silenciosamente.
Resolver todos os hunks de um arquivo grande de uma vez sem revisar cada um isoladamente — aumenta a chance de aceitar um hunk errado por fadiga.
Confiar em git rerere para repetir uma resolução anterior sem reconfirmar que o contexto ao redor não mudou o suficiente para invalidar a resolução gravada.

git status sem nenhum arquivo unmerged e sem marcador de conflito residual em nenhum arquivo (grep por <<<<<<< no diretório de trabalho).
Diff combinado revisado hunk a hunk contra a intenção reconstruída de ambos os lados.
Typecheck, build e testes focais dos arquivos tocados executados, mais a suíte de regressão relevante ao comportamento integrado.
Histórico resultante e o destino do push (branch, force ou não) confirmados antes de publicar — nunca publicar uma resolução sem essa checagem quando o histórico foi reescrito.
Não declarar a integração “resolvida” sem essa evidência — resolução sem build/teste revalidado é apenas ausência de marcador, não correção comprovada.

$specsfy-specialist-code-review para revisar o resultado combinado como qualquer diff novo, já que a resolução pode introduzir comportamento não coberto pelos PRs originais isoladamente.
$specsfy-specialist-domain-modeling quando o conflito semântico revelar que dois lados modelaram o mesmo conceito de domínio de forma incompatível — o conflito é sintoma de um boundary não alinhado.
$specsfy-specialist-gitflow quando o merge/rebase em conflito envolver feature/, release/ ou hotfix/ de um projeto que declarou Gitflow — aquela skill decide a topologia e o destino do merge, esta resolve o conflito textual ou semântico já aberto.

Leia references/standards.md para comandos de diagnóstico, tipos de conflito sem marcador textual e fontes oficiais do Git.