git push: branch, tracking, upstream

git push pubblica commit locali su un remote. Ma per farlo bene devi sapere quale branch locale sta parlando con quale branch remoto.

L’upstream è l’associazione tra branch locale e branch remoto. Quando è configurato, Git sa dove pushare e da dove pullare senza argomenti.

Perché questa lezione conta

Molti push sbagliati avvengono perché il branch non ha upstream, ha upstream errato o la configurazione push.default è troppo permissiva.

In team, un push sbagliato può aprire PR contro branch errato, aggiornare branch remoto non voluto o tentare di modificare main.

Obiettivo operativo

Alla fine della lezione devi saper pubblicare un branch con upstream, leggere tracking branch, scegliere push.default e rispettare branch protetti.

Primo push di un branch

git switch -c feat/login
git push -u origin feat/login

-u significa --set-upstream. Da questo momento:

git push
git pull

sanno usare origin/feat/login.

Controlla:

git branch -vv

Output:

* feat/login abc1234 [origin/feat/login] aggiungi form login

push.default

Config consigliata per molti sviluppatori:

git config --global push.default current

Con current, Git pusha il branch corrente verso un branch remoto con lo stesso nome.

Altra opzione comune:

git config --global push.default simple

simple richiede upstream con stesso nome ed è più conservativa.

Evita configurazioni che pushano molti branch insieme se non sai perché ti servono.

Push di tag

I tag non vengono sempre pushati automaticamente:

git push origin v1.2.0
git push origin --tags

--tags pusha tutti i tag mancanti. In release serie, preferisci push mirato del tag che stai pubblicando.

Branch protetti

Su GitHub/GitLab, main dovrebbe essere protetto:

1. niente push diretto;
2. PR obbligatoria;
3. review richiesta;
4. CI verde;
5. no force push;
6. eventualmente signed commits.

Git locale non basta a proteggere il team. Le regole devono vivere anche sulla piattaforma.

Prima di pushare

Routine:

git status -sb
git log --oneline @{u}..HEAD
git diff --stat @{u}..HEAD

@{u} è upstream del branch corrente. Se non esiste, Git te lo dirà.

Push esplicito quando serve

Quando stai facendo un’operazione delicata, preferisci la forma completa:

git push origin HEAD:feat/login

Si legge così: prendi il mio HEAD locale e aggiornalo sul branch remoto feat/login. È più verbosa, ma elimina ambiguità quando il branch locale ha nome diverso, quando stai lavorando in un worktree o quando vuoi essere certo della destinazione.

Non serve usarla sempre. Serve conoscerla per i momenti in cui un push generico sarebbe troppo opaco.

Laboratorio guidato

In un repo demo remoto o sandbox:

1. crea branch locale;
2. fai due commit;
3. prova git push senza upstream e leggi errore;
4. fai git push -u origin <branch>;
5. verifica git branch -vv;
6. fai nuovo commit e pusha senza argomenti;
7. cambia push.default e osserva differenze.

Output atteso

Una configurazione:

push.default = current oppure simple
main protetto sul remoto
branch feature pushati con -u
tag pushati esplicitamente

Errori comuni

Pushare senza sapere l’upstream. Controlla git branch -vv.

Pushare tag tutti insieme. Può pubblicare tag sperimentali.

Lasciare main non protetto. La policy locale non basta.

Usare nomi branch diversi locale/remoto senza motivo. Aumenta confusione.

Checklist di verifica

• so usare git push -u;
• so leggere git branch -vv;
• so configurare push.default;
• so usare @{u};
• so distinguere push di branch e push di tag.

Collegamenti

• Modulo: Collaborazione con remoti — lezione 23 del corso.
• La lezione successiva copre il caso delicato: force push.