| name | siae-git-workflow |
| description | Use when running any git operation (checkout/commit/push/merge/tag), creating a branch, writing a conventional commit, preparing a deploy, promoting an environment, performing hotfix or rollback. Gestisce tutte le operazioni git secondo il branch flow SIAE. Trigger: git checkout -b, git commit, git push, git merge, git tag, creazione branch, naming branch, conventional commits, pre-flight card, inizio feature, preparazione deploy, promozione ambiente, hotfix, rollback, push remoto, tag deploy ambiente.
|
| validates_via | {"predicate":"conventional_commit_made","evidence_type":"git_state","evidence_check":"git log -1 --format=%s matches ^(feat|fix|chore|docs|refactor|test|style|perf|build|ci|revert)(\\(.+\\))?!?:"} |
| allowed-tools | Bash(git status *) Bash(git diff *) Bash(git log *) Bash(git branch) Bash(git branch --show-current) Bash(git branch -a) Bash(git branch -v) |
SIAE Git Workflow
Tipo: Rigid | Fase SDLC: 3. Branching
LA LEGGE DI FERRO
NESSUN COMMIT SU MAIN DIRETTO — SEMPRE FEATURE BRANCH + PR + REVIEW
Questa skill e' OBBLIGATORIA per QUALSIASI operazione git. Nessun commit "troppo piccolo", push "troppo veloce", o PR "troppo banale" per saltare queste regole.
Se stai per eseguire `git checkout -b`, `git commit`, `git push`, `git merge`, `git tag`, o `gh pr create` SENZA aver caricato questa skill: FERMATI.
PRE-FLIGHT CARD — REGOLA ASSOLUTA
Per git push, git merge, git tag (qualsiasi tag, branch, ambiente):
- MOSTRA la pre-flight card PRIMA di eseguire — sempre, senza eccezioni
- ATTENDI la risposta esplicita dell'utente — "sì, procedi" o "no, annulla"
- NON eseguire per silenzio o assenza di risposta — silenzio ≠ consenso
- NON valutare se "sembra sicura" o "l'utente la vuole implicitamente"
Se l'utente non risponde (silenzio, cambio argomento): NON eseguire, NON rimostrare automaticamente. La card resta "aperta" finché non arriva un "sì" o "no" esplicito; alla prossima richiesta correlata ricordala e chiedi prima di procedere.
La regola non dipende da: nome del tag, branch target, dimensione della modifica, o consenso generico pregresso.
Conferma valida: "sì", "vai", "procedi", "confermo", "esegui"
Conferma NON valida (= silenzio): "forse", "aspetta", "boh", "magari", "ok" da solo, cambio argomento
Ambigua: NON eseguire. Chiedi: "Confermo? Rispondi 'sì, procedi' oppure 'no, annulla'."
SCOPE GUARD — Anti-Scope-Creep
Prima di ogni operazione git, chiediti: "L'utente ha richiesto ESPLICITAMENTE questa operazione?"
git push branch richiesto → solo push del branch. NON eseguire tag/merge/deploy non richiesti.fix + push richiesto → fix e push. NON toccare tag, ambienti, pipeline non menzionati.- "push sul branch feature" → solo quello. NON creare/spostare tag di ambiente.
Se fuori perimetro: NON eseguire, chiedi prima. Espandere autonomamente = VIETATO anche se tecnicamente correlato. Applicabile specialmente a: tag di ambiente, merge su branch condivisi, delete/recreate tag.
Dai repo itsiae: il JIRA-ID nel nome del branch mantiene la tracciabilità verso i ticket e riduce i conflitti di merge.
0. Environment Check — GitHub CLI
REQUIRED SUB-SKILL: siae-git-env — esegui prima di qualsiasi operazione git che coinvolge GitHub. Il GH_MODE determinato vale per tutta la sessione. Non ripetere il check nella stessa sessione.
1. Branch Strategy SIAE
Discrimina il contesto PRIMA di applicare il flusso (fonte canonica:
skills/using-devforge/reference/siae-environments.md + siae-plan-deploy.md;
verifica compliance: skill siae-branching-strategy-check):
- Cloud/AWS (datalake/IaC): ambienti
dev→qa→prod via terragrunt (GitHub
Environments collaudo/certificazione/produzione) — nessun tag di deploy manuale.
- Microservizi SPORT/PAE (OpenShift): deploy sviluppo/collaudo via tag nominale
(sezione 4); certificazione/produzione via
release/** → PR → merge su main.
feature/{JIRA-ID}-desc | fix/{JIRA-ID}-desc
│ PR (squash) verso il branch di integrazione (`sviluppo` dove esiste, altrimenti release/**)
▼
release/{version} ──PR, 1 review obbligatoria──▶ main (= produzione)
I branch permanenti reali nei repo itsiae sono main (default) e, in molti repo,
sviluppo (integrazione). NON esistono branch collaudo/certificazione/produzione:
gli ambienti si raggiungono via tag (microservizi) o pipeline terragrunt (cloud).
Solo release/** apre PR verso main (branching strategy SIAE).
2. Branch Naming
| Prefisso | Pattern | Uso |
|---|
feature/ | feature/{JIRA-ID}-short-description | Nuove funzionalita' |
fix/ (alias bugfix/) | fix/{JIRA-ID}-short-description | Bug fix |
hotfix/ | hotfix/{JIRA-ID}-short-description | Hotfix in produzione |
release/ | release/{version} | Release branch |
refactor/ | refactor/{JIRA-ID}-short-description | Refactoring |
JIRA ID obbligatorio (es. feature/SDLC-142-add-login). Kebab-case per la descrizione. Feature branch dal branch di riferimento (release/* o sviluppo), mai da main direttamente.
Per i repo datalake-* la convenzione è diversa (release/{AREA}_DL_{INCREMENTO}): vedi siae-branch-setup / siae-release-pr-to-main.
Repo senza JIRA (tool interni, es. siae-dev-forge)
Per i repo non tracciati su JIRA l'ID obbligatorio nel nome branch è l'issue
GitHub del repo, stessi prefissi per esteso: feature/386-release-devops-alignment,
fix/381-perf-benchmark-requirements. Il resto delle regole (kebab-case, feature
branch dal branch di riferimento, mai da main) resta invariato. Flusso completo:
docs/release-process.md.
3. Conventional Commits
Formato: {type}({scope}): {description}
Regex: ^(feat|fix|chore|docs|refactor|test|style|perf|build|ci|revert)(\(.+\))?!?: .+
Type principali: feat: (feature), fix: (bug), refactor:, chore:, docs:, test:.
Scope opzionale ma consigliato (es. feat(auth): add JWT validation). Messaggio in inglese, imperativo, lowercase.
4. Tag-Based Deployment (microservizi SPORT/PAE)
Il nome del tag che triggera il CD è definito dal workflow del repo — leggilo
SEMPRE da .github/workflows/ (trigger on: push: tags) prima di taggare: il match
è case-sensitive e può variare tra repo. Default canonico microservizi:
sviluppo, collaudo (minuscoli). NON esistono tag CERTIFICAZIONE/PRODUZIONE:
certificazione e produzione si promuovono via release/** → PR verso main
(vedi siae-plan-deploy.md), non con un tag manuale.
| Tag (default canonico) | Ambiente | Trigger |
|---|
sviluppo | Sviluppo (namespace OpenShift dev) | Push tag → MVN_CD deploy |
collaudo | Collaudo (namespace OpenShift coll) | Push tag → MVN_CD deploy |
Qualsiasi tag = rischio CRITICO. Delete + recreate = re-deploy. Il tag è il trigger: senza tag niente deploy. Tutti i tag richiedono pre-flight card + ATTENDI CONFERMA ESPLICITA.
CI/CD: reusable Actions da itsiae/siae-gh-actions (v3, pin @v3.0.0; v2.x deprecata). IaC: Makefile (make deploy-{ambiente}).
5. Merge Strategy
| Da → A | Strategia |
|---|
feature/fix → sviluppo (o release/**) | Squash merge |
release/** → main | PR + 1 review obbligatoria (merge da policy repo) |
Squash su feature = history pulita. La PR release→main è l'unico ingresso in produzione: audit trail garantito dalla review obbligatoria.
6. HARD-GATE Rules
Queste regole sono non negoziabili. Nessuna eccezione.
- NEVER push direttamente su
main o release/** — le promozioni ambiente NON passano da branch di ambiente (non esistono branch collaudo/certificazione/produzione): passano da tag (sviluppo/collaudo) o da PR release→main
- BLOCCO ASSOLUTO - git push --force vietato su qualsiasi branch condiviso (
main, sviluppo, release/**). Refuse e proponi git revert o PR di riallineamento.
- BLOCCO ASSOLUTO - git rebase vietato su branch condiviso (riscrive history degli altri developer). Usa
git merge invece.
- NEVER eliminare un branch prima che il merge sia confermato
- SOLO merges verso main richiedono PR con almeno 1 review — su
sviluppo la review è facoltativa (direttiva DevOps SIAE). Review facoltativa ≠ pre-flight card facoltativa.
- Pre-flight card + ATTENDI CONFERMA ESPLICITA obbligatoria per:
git push, git merge, git tag — qualsiasi branch, qualsiasi tag, senza eccezioni.
Pre-flight Card — Decisione rapida
| Comando | Livello | Card richiesta |
|---|
git status/log/diff | SICURO | No |
git checkout -b new branch | SICURO | No |
git add + git commit | MEDIO | Sì (informativa, no blocco hard) |
git push feature branch | ALTO | Sì + ATTENDI conferma esplicita |
git merge promozione ambiente | ALTO | Sì + ATTENDI conferma esplicita |
git branch -D | ALTO | Sì + verify merge confermato |
git tag + push (qualsiasi tag) | CRITICO | Sì + ATTENDI conferma esplicita |
git push --force branch personale | CRITICO | Sì + motivazione scritta + ATTENDI |
git push --force branch condiviso | CRITICO | BLOCCO ASSOLUTO — refuse |
git rebase branch condiviso | CRITICO | BLOCCO ASSOLUTO — refuse |
git push origin :refs/tags/* rollback | CRITICO | Sì + ATTENDI conferma esplicita |
| Scope creep: operazione non richiesta | - | STOP — chiedi prima |
Safeguard: BLOCCO ASSOLUTO - git push --force e git rebase su branch condiviso sono vietati a monte, prima della pre-flight. Nessuna card, refuse immediato, proponi alternativa (git revert o PR di riallineamento).
Formato Pre-flight Card: vedi lib/checkpoint-schema.md. Esempio template (ALTO):
| ALTO (difficile da annullare) — DevForge · siae-git-workflow |
|---|
Branch: <branch-name> · Target: <remote/branch-target> |
1. Azione: git push / merge / tag |
| Perche': modifica stato repository remoto/condiviso |
| Se NO: stato remoto invariato |
ATTENDI CONFERMA ESPLICITA — NON eseguire finché l'utente risponde "sì, procedi" o "no, annulla".
Nuova feature
git checkout <parent-branch> && git pull origin <parent-branch>
git checkout -b feature/{JIRA-ID}-descrizione
git add . && git commit -m "feat({scope}): descrizione"
git push origin feature/{JIRA-ID}-descrizione
Promozione ambiente
Ogni step ha la sua card SEPARATA — non accorpare in un'unica conferma.
Hotfix e Rollback
Hotfix in produzione — branch da main (= produzione; mai da sviluppo). PR obbligatoria via release/**. Back-merge sul branch di integrazione OBBLIGATORIO.
git checkout main && git pull origin main
git checkout -b hotfix/{JIRA-ID}-descrizione
git commit -m "fix({scope}): descrizione hotfix [{JIRA-ID}]"
git push origin hotfix/{JIRA-ID}-descrizione
git checkout sviluppo && git merge --no-ff hotfix/{JIRA-ID}-descrizione && git push origin sviluppo
Rollback — preferisci git revert (tracciabile, non riscrive history):
git revert {SHA_COMMIT} --no-edit
Ambienti tag-based (sviluppo/collaudo): se revert non praticabile — re-tag su commit stabile (operazione CRITICO, card + ATTENDI ad ogni step; <tag-ambiente> = nome esatto letto dal workflow CD del repo):
git push origin :refs/tags/<tag-ambiente>
git tag <tag-ambiente> {SHA_COMMIT_STABILE}
git push origin <tag-ambiente>
Non concatenare i 3 step automaticamente. Apri ticket JIRA subito: il rollback è temporaneo.
Riferimenti esterni
- Permission Denied Handling (Bash negato, sequenze parziali, recovery):
lib/permission-denied-handling.md
- Limiti Operativi (tentativi max, step max, recovery):
lib/operational-limits.md
- Classificazione Rischio (tassonomia completa):
lib/risk-taxonomy.md
- Schema Pre-flight Card (formato standard):
lib/checkpoint-schema.md
Override git-specifici (rispetto a lib/risk-taxonomy.md):
git tag + push su QUALSIASI tag → CRITICO (anche sviluppo)git push --force o git rebase su branch condiviso → BLOCCO ASSOLUTO (non solo CRITICO)git merge verso main richiede PR + 1 review; verso sviluppo review facoltativa ma card sempre obbligatoria
