Registra il lavoro accettato con un commit

Un’implementazione riuscita non autorizza automaticamente un commit Git. TCAF tratta review, accettazione, commit, tag e push come decisioni distinte.

Prima del commit

Verifica che:

• il Task Contract sia stato approvato;
• il diff finale corrisponda al perimetro autorizzato;
• le modifiche del developer siano incluse e preservate;
• i controlli pertinenti siano stati eseguiti o chiaramente indicati come pendenti;
• file collaterali non vengano aggiunti accidentalmente allo staging;
• riconciliazione di documentazione o backlog sia inclusa intenzionalmente oppure gestita separatamente;
• il developer abbia accettato esplicitamente il risultato.

Ispeziona il working tree:

git status --short
git diff --check
git diff --stat

Revisiona diff mirati per file invece di affidarti a un unico output terminale troppo esteso.

Aggiungi allo staging soltanto i file accettati

Preferisci percorsi espliciti:

git add <file-accettato-1> <file-accettato-2>

Poi controlla lo staging:

git diff --cached --check
git diff --cached --stat

Crea il commit

Usa un messaggio che descriva il risultato accettato:

git commit -m "<messaggio-chiaro-e-circoscritto>"

Il commit non deve includere lavoro locale non pertinente, file del framework, regole private degli strumenti o artefatti generati fuori dal perimetro accettato.

Push, tag e pull request sono separati

Non eseguire push, creare tag, aprire pull request o aggiornare issue remote soltanto perché il commit esiste. Ogni operazione remota richiede autorizzazione propria e controllo del branch di destinazione e dello stato del repository.

Riporta il completamento

Restituisci SHA del commit, perimetro incluso e controlli eseguiti. Non dichiarare la pubblicazione remota se push o pull request non sono realmente riusciti.