Push — cosa significa, come funziona git push e quando serve

Cosa sono un push in Git

Git push è un comando che trasferisce i commit da un repository locale a uno remoto. A differenza di un commit, che salva le modifiche solo sulla macchina locale dello sviluppatore, un push pubblica quelle modifiche per l’intero team. Push è un passaggio obbligatorio prima di creare una Pull Request e del deploy.

L’architettura di Git presuppone che ogni sviluppatore lavori nel proprio repository locale. I commit vengono creati localmente e si accumulano fino a quando lo sviluppatore decide di fare push. Questo offre libertà: puoi fare molti commit locali, sperimentare e riscrivere la cronologia senza influenzare i colleghi.

# Push verso il remote origin, branch main
git push origin main

# Push del branch corrente verso il remote con upstream
git push -u origin feature/new-dashboard

# Push di tutti i branch con nomi corrispondenti
git push --all origin

# Force push con lease (force push sicuro)
git push --force-with-lease

Dopo un push, il repository remoto aggiorna i ref (riferimenti ai branch) in modo che puntino ai nuovi commit. Altri sviluppatori possono recuperare queste modifiche tramite git pull o git fetch. Questo scambio di commit costituisce la base dello sviluppo collaborativo.

Come funziona git push

Il comando git push confronta i branch locali e remoti e trasferisce solo i commit mancanti. Git non reinvia tutti i file — trasferisce solo il delta, rendendo il push veloce anche per repository di grandi dimensioni. Protocollo Git utilizza il trasferimento intelligente, che minimizza la quantità di dati trasmessi.

Se il branch remoto contiene commit non presenti localmente, il push verrà rifiutato. Questo è un meccanismo di protezione che impedisce la perdita di modifiche. In questa situazione, lo sviluppatore deve prima eseguire git pull, unire le modifiche e solo dopo ripetere il push. Un’alternativa è il force push, che sovrascrive il branch remoto, ma va usato con cautela.

Comprendere i repository remoti è la chiave per un push corretto. Di solito, origin è il nome predefinito del repository remoto. Il comando git remote -v mostra l’elenco dei repository remoti e i loro URL. Puoi aggiungere più remote (ad esempio, origin per il repository principale e upstream per un fork).

Quando fare push delle modifiche

La regola principale: fare push dopo ogni fase di lavoro logicamente completata. Se uno sviluppatore ha terminato un’attività o una parte di essa — è ora di fare push. Tuttavia, fare push di lavoro non finito che rompe la build non è consigliato. Build non rotta è il requisito minimo per fare push in qualsiasi branch.

Nello sviluppo di team viene adottato il seguente ritmo: al mattino — git pull per ottenere le modifiche dei colleghi, durante il giorno — diversi commit e uno o due push, alla sera — un push finale di tutte le attività completate. Più spesso uno sviluppatore fa push, minore è il rischio di conflitti di merge e più trasparente è l’avanzamento del lavoro.

• Dopo aver completato un’attività — committare e fare push della soluzione finale nel branch feature
• Prima di andare via — fare push del lavoro non finito in un branch feature (non in main!)
• Prima di creare un PR — assicurarsi che tutti i commit siano stati pushati e disponibili per la revisione
• Dopo rebase — fare push con --force-with-lease nel tuo branch feature

Regole per un push sicuro

Il push sicuro è un insieme di regole che prevengono la perdita di dati e i conflitti nel team. La prima e più importante regola: non fare mai push direttamente nel branch main o master se il progetto non ha un deploy diretto configurato. Nei team moderni, la protezione del branch main viene configurata a livello di protezione del branch GitHub.

La seconda regola: sincronizzati con il branch remoto prima di fare push. Esegui git pull --rebase per evitare commit di merge durante l’unione. Questo semplifica la cronologia e la rende lineare. Se un push viene rifiutato — non usare un semplice force push, ma scopri prima quali commit sono apparsi sul branch remoto.

La terza regola: configura hook pre-push che eseguano automaticamente test e linter prima dell’invio. Se i test falliscono — il push viene bloccato. Questi hook vengono configurati tramite Husky o Git hook (file pre-push in .git/hooks).

La quarta regola: non fare push di file binari di grandi dimensioni. Git non è progettato per memorizzare artefatti binari — gonfiano il repository e rallentano le operazioni. Per file grandi, usa Git LFS (Large File Storage). Se un binario è già stato pushato e si trova nella cronologia, deve essere rimosso tramite git filter-branch.

Cosa fare se il push fallisce

La causa più comune di un push fallito è che il branch remoto contiene commit non presenti localmente. Ciò accade quando un altro sviluppatore ha pushato le sue modifiche nello stesso branch. Soluzione: esegui git pull, risolvi eventuali conflitti e ripeti il push.

# Push rifiutato — prima fetch e rebase
git fetch origin
git rebase origin/main
# Risolvi i conflitti, poi:
git push --force-with-lease

# O semplicemente unisci le modifiche remote
git pull origin main
git push

La seconda ragione — mancanza di permessi di scrittura sul branch. Se il branch main è protetto da regole di protezione del branch, i push diretti sono vietati. Soluzione: fare push in un branch feature e creare una Pull Request. Le impostazioni di protezione vengono solitamente amministrate tramite le impostazioni di GitHub o i branch protetti di GitLab.

La terza ragione — problemi di autenticazione. Credenziali obsolete, passaggio a SSH o modifica del personal access token. Soluzione: controlla l’URL remoto (git remote -v) e aggiorna le credenziali. Dal 2021, GitHub ha eliminato l’autenticazione con password per HTTPS — usa un token personale o una chiave SSH.